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I. INTRODUCTION 



Tne bacKtracK control strategy nas neveiopeci Into one of 
tns major classes of aleoritftms since its first appearance 
in tne literature of computation. This nas been recognized 
by many autnors and most current teitbooKS on alsoritnms, 
including tnose by Ano, Hopcroft and Oilman [Ref. ij and 
Horowitz and Sanni [Ref. 2], include substantial sections on 
tne strategy. SJcill in tne development of bacKtracK 
aigoritnms can be as useful to programmers as tneir Sitill 
irfitn otner general algorithm classes, sucn as tne divide and 
conquer, greedy and dynamic programming control strategies. 
A minor goal of tnis paper is to further refine knowledge of 
the structural relationships within a oacKtracK algorithm. 

This expert Knowledge of bacKtracK proe*ramming 
techniques can also be used in the program synthesis 
process. The problem reduction approach to program 
synthesis detailed in Smith [Ref. 3, employs reduction 
rules in the form of algorithmic schemas and supporting 
heuristic Knowledge concerning subschema specification to 
decompose a problem specification to a series of simpler 
specifications. Program solutions to these 
subspecifications are ultimately composed via tne schema 
structure into a program satisfying the original 
specifications. The major goal of this paper is to produce 
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two SUCH sctiemas for tne DacittracK control stratee*/ ana two 
CO rresponai ng design (Tiettiods for employing tnese scuerras. 

Tne first discussion of bacttracK by Walicer [Ref. 5j was 
a fairly general description of a tecnnique tnen in use for 
deciding combinatorial problems. Furtner descriptions of 
tne tecnnique, sucn as (Jolomb and Baumert [Ref. 6J and 
Bitner [Ref. 7J were oriented towards tne efficiency aspects 
of tne strategy. This approacn to tne study of bacictracK 
algoritnms was reflected in texts on combinatorial 
algoritnms, sucn as tnat by Reingold, Nievergelt and Deo 
[Ref. 8J . Witn tnis empnasis on tne development of 
specialized tecnniques for improving efficiency tne study of 
tne general properties of tne bacKtrack class was 
overlooked. Tne paper by Gernart and lelowitz [Ref. 9j 
reversed tnis trend. Tney developed a series of backtrack 
scnemas differentiated oy tne type of control (recursive or 
iterative) and tne type of solution (first, all or optimal) 
desired, Tne empnasis was on tne development of scnemas 
proven to be correct along witn general specifications for 
tne subschemas wnicn would aid in proving tne correctness of 
tne algorithms developed to complete tne program. 

Tnis paper attempts to address two perceived gaps in tne 
understanding of backtrack algorithms. The first gap lies 
in the development of schemas in a notation suitable for 
automated program synthesis. This notation snouid allow for 
simpler program verification techniques than those used by 
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IJernart anl Teiowiiz. Tae scnemas snouil also De accompani ec 
by heuristics for instantiation of tne scnema to satisfy a 
sriven problem specification. Chapters II, III and 17 will 
address these cohcerns by describing the program synthesis 
system (Chapter II), the characteristics of a bacitracir 
algorithm (Chapter III) and a bacKtracit program schema and 
associated design method (Chapter 17). The second ?ap lies 
in the extension of the bacittracK strategy to solve a class 
of problems which have not generally been solved by a 
bacttract control structure in tne past. Chapter 7 will 
develop a scnema and associated design method for searching 
a solution sraph of a problem with a hierarchical 
structure. Chapter 71 will conclude this paper and point to 
further areas of research. 
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II. THE PROGRAM SYNTHESIS SYSTEM 



Tne program syntnesis 


model 


for this 


resea rc 


n is 


tne 


problem reduction approacn 


as 


developed 


oy 


Smi tn 


[Ref . 


liJ» 


11] . Tnis approach is 


an 


attempt 


to 


form 


aii ze 


tne 


programming discipline of 


top down design 


as 


a hie 


rarchi 


cal ♦ 



problem reluction structure. A brief examination of this 
model will nelp Identify tne type of icnowledge required to 
syntnesize a bacKtracK program. 

A. TEE PROJ3LEM REDUCTION MODEL 

Tne Hey concept in tnis model is tnat program 
development by top down design is a problem reduction 
approacn to tne programming problem. Top down design is 
accomplisned tnrougn successive refinement of a problem 
specification into a series of simpler subspecifications. 
These subspecifications are related tnrougn control 
structures wnicn direct control tnrougn tne subprograms. At 
each step of tne refinement process tne subspecifications 
from the previous step are furtner refined. Tnis continues 
until all are replaced by tne primitive constructs of tne 
programming lan^rua^e. The entire program is tnen composed 
from tne primitive language constructs ana control 
structures produced during tne refinement stages. 

A problem reduction problem solving approacn attempts a 
solution by applying reduction operators to a problem goal 
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statement. These reduction operators decompose tne ^oai 
into a number of simpler sub^oals and additionally provide a 
framewort for composing the solutions to the sub^oals into a 
solution to tne original problem ^oal. Also required is a 
set of primitive operators which allow direct solving of a 
subgoal. By successively decomposine a problem until a 
primitive operator can be applied to each sub^oal and then 
composing these solutions with the structure provided by the 
reduction operator, a solution to the original problem is 
found . 

The analogy between problem red ction problem solution 
and top down design is obvious. The goal statement in a 
program synthesis system is a formal specification of a 
problem. A primitive operator of a program synthesis system 
is a proerammincr lansuaffe construct. Tne reduction 
operators include a procedure for developing 
subspecifications (design strategy in Smith [Ref. 12j f 
design method above) and a structure for composition of tne 
subspecification solutions. The structures chosen for the 
reduction operators are program schemas wnicn reflect the 
different control strategies. Tne program synthesis problem 
is to develop a program schema /design method pair wnicn 
allows synthesis of correct programs. 

A simple example should help illustrate this process. 
Suppose our specification requires tne selection of the 
maximum of two natural numbers given as input. Tne goal 
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specification may looli lite: 

MAX(a,b) = C sucn tnat 
[A>=b <=> C=AJ 6. 

[B>A <=> C=BJ 

where MAX: (NiN) -> N 

Tnis specification for a function named MAX states tnat MAX 
tatces two natural numbers as input and returns a single 
natural number. Tne logic specification consists of a 
conjunction of two clauses. £acn clause must therefore be 
true for the output to be correct. Both conjuncts are 
logical equivalences, which reouires both sides of tne 
equivalence to be true or both sides false for tne 
equivalence to be true. Thus we have a specification in 
Which if A>=B, C must equal A, and if B>A, C must equal B. 
Thus C must be tne maximum of A and B. If our programming 
language nad a suitably defined function MAX(X,I), then a 
primitive solution to this goal could be applied. If not, 
tne goal must be further reduced to allow for solution. One 
reduction rule wnicn could be applied is a simple 
conditional. With this rule a control scnema would oe 
imposed and subspecifications would be developed for tne 
schema slots. The schema may loos lise: 

if ? 
then F 
else G 

tfnere P, F, G are functions the rule will specify. The 
specifications produced by tne rule may be: 
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P:(A,B) = b sucn tnat 
[A>=B <=> t)J 
where P : ( NxN ) -> B 

F:A = C sucn tnat 
[A = CJ 

where F:N -> N 

G :B = C sucn tnat 
[B = CJ 

where F:N -> N 

Vith these specifications P can oe directly solved by a 

simple relational operator anl F and G can oe solved by an 

assignment operator, and tne final program produced will be: 

MAX(A,B) = 
if A>=B 

tnen C <- A 
else C <- B; 
return C 



B. PROBLS:^ SPSCIFICATION 

Tne program synthesis system requires a formal 

specification of a problem. This formal specification is a 

logical description of the input/output relationships for 

the program. The following format will be used to specify 

problems in this paper: 

F:x = 2 sucn tnat I :x => 0:<x,2> 
where F:D -> R 

In this instance, F is tne name of tne specification and tne 
: operator indicates function application. 

There are four components to a formal specification. 
The input condition I details all Known properties of 
objects input to the program. If tne input condition 
applied to some object x is true, tnen tne program must 
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produce tne specified output. In many cases tne input 
condition will be vacuously true. Tne output condition 0 
specifies the relations tnat are expected to nold oetween 
tne input objects and tne output objects. Tne domain D 
specifies the data type of input objects and tne ran^e R 
specifies the data type of output objects. The program 
synthesis system will attempt to derive a program F wnicn 
takes as input an object of type D and produces as output an 
object of type R. If tnis input object satisfies the input 
condition then the output condition applied to tne input and 
output objects will be true. 

C. THS PROGRAr^f^lNG LANGUAGE 

Tne target programming lansua^e for this system is a 
functional language similar to Backus' FP notation [Hef. 
13J . A functional language provides several advantages to 
tne program synthesis process. Tne most significant is tne 
relative ease of program verification. Although not a 
trivial task, the proof techniques are more manageable tnan 
those for procedural lancuases. The principal reason for 
tnis lies in the nature of expressions. A functional 
program constitutes a single expression. Within tnis 
expression all occurences of a name or subexpression nave 
the same value. Thus tne statement by statement state 
Changes within a procedural lan^uace which create most of 
the difficulty in program verification do not exist with 
functional programs. Tnis permits an algebra of functional 
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programming, as iiactcus further discusses [Ref. 14j wnlch 
permits use of tne language as a proof tool. A second 
alvantaes lies in tne nierarcnic nature of functional 
lansuaffes. Higher level functions are constructed from 
lower level functions and appropriate comoining functional 
forms. The reduction rules in the synthesis system are 
actually methods for producing specifications for lower 
level functions and schemas wnicn connect tne specifications 
with the appropriate comOinine forms. 

A functional language contains a set of five components 
[Ref. 15J , wnicn are: 

1. a set of objects 

2. a set of functions 

3. the application operation 

4. a set of functional forms 

5. a function definition mechanism 

The functional lan^ua^e used is fully described in Appendix 
A. Tne following paragraphs highlight tne major differences 
between Eacxus' notation and tne language notation used. 

1 ♦ Set of 0 b j^e c t s 

The set of objects in this language include specific 
lata types. The particular data types which will be 
necessary in this paper are N, the natural numbers, LIST(N), 
lists of natural numbers, I, the integers and B, the boolean 
values true and false. Also included is tne data structure 
<>, sequences of objects. 
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2 • Set of Pri (HiiilS. Functions 

Ttie set of primitive functions are tied to tne 
various data types and structures. A complete set of 
functions is given in Appendix A. 

Tne Appl ication Operation 

Function application is ennanced by allowing tne use 
of named parameters in botn tne application and definition 
of functions. Tnis deviates greatly from BacKus' 
intentions, but obviates mucn of tne use of selector 
functions in data manipulation. At tne least it increases 
tne clarity of function definitions. A furtner motivation 
is the Knowledge tnat efficient algorithms [Ref.iej exist to 
extract named parameters from function definitions. A 

declaration mechanism is also included to allow for 
controlling name visibility. 

^ • The Function Definition I^iecnan i sm 

An anonymous function definition mecnanism, similar 

to the LISP lambda function, is included. The syntax is: 

(lambda <parameter list> 

{function definition}) 

(actual parameter list) 

This will be most useful for scnema expression, as it allows 
for fully specifying a lower level function within a higher 
function. In tne bacttracK scnema we snail use this feature 
to express a lower level function in terms of its component 
functions, thereby directly expressing all components of tne 
bacKtracK strategy and their relationships. 
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III. THE BACKTRACK CONTROL STRATEGY 



The bacKtractt control strategy is essentially a 
technique applicable to combinatorial problems. A bacictracJt 
algorithm tarlll conduct an uninformed search of a state space 
to select those states which satisfy the problem 

constraints. The advantaere of a bacKt racttin^ algorithm over 
other uninformed search techniques Is that it can employ the 
problem constraints to prune tne state space tree, thus 
reducing the amount of search required. 

A. STATE SPACE SEARCH 

A. state space problem representation attempts to define 
a problem through description of the various states of the 
problem world and methods in tne problem world for 

transforming a given state into a new state. In the 

computer solution of state space problems tne fundamental 
concepts are the symbolic representation of the relevant 
aspects of the problem state and tne computation of 

permissible state transformations. These permissible 

transformations are problem world related in that they 
represent transformations the problem world would permit. 
For example, a permissible transformation may well lead to a 
problem state which violates a constraint, but is an 

allowable action in tne world being modelled. Tne solution 
technique most often used to solve state space problems is 
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some form of searcn. 



Tne searcn commences at a ^iven 



initial state and proceeds tnrou^n a directed srapn,. wnere 
tne grapn nodes represent tne possible states and tr.e arcs 
represent tne permissible transformations. Tne searcn 

terminates wnen a goal state is reacned. 

An illustrative example is tne missionaries and 
cannibals problem. In tnis problem we are given an equal 
number of missionaries and cannibals on a river DanK and a 
boat wMcn can hold at most two persons. Tne goal is to get 
ail missionaries and cannibals to tne otner bans witnout 
leaving more cannibals tnan missionaries on eitner tanir at 
any time. To represent tnis problem witn a state space 
representation we must identify tne relevant aspects of 
state and develop a symbolic representation for tnem. We 
must also develop routines to compute allowable 
transformations between state descriptions. Tne solution to 
tnis problem will be a sequence of transf orma ti ons wnicn 
move tne missionaries and cannibals from one oanit to tne 
otner and wnicn do not violate tne problem constraints. 

A number of techniques exist for searcnlng state space 
graphs. Tney differ principally in tne technique used for 
selecting wnicn already visited state to expand, or to 
transform to a new state. Uninformed techniques sucn as 
depth first, breadtn first and generate and test searcn 
transform unown states in an arbitrary and fixed manner. 
The bacKtracfc strategy, as we snail see, is an example of an 



uninformed search. An informed lecnnlque, sucn as oesi 
first search, will use some type of Knowledge to evaluate 
the Known states and select the most promising of these for 
expansion. The decision of wnether to use an informed or 
uninformed search is most often a function of tne proolem 
and now well search Knowledge can be codified. 

B. GENERAL DESCRIPTION OF APPLICABLE PROBLEMS 

BacKtracK is suited for the solution of comoina tcrial 
problems which exhibit certain characteristics. These 
characteristics include the ability to segment tne problem 
into a set of discrete out interrelated decisions, a 
solution structured as a vector of decisions, and a set of 
testable solution constraints which relate the decision 
elements . 

1 • Pfo b^em Characteristi cs 

Representation of a problem as a set of 
discrete decisions structures the problem into a tree search 
probiem. Each node of the tree represents a decision to be 
made and each arc from that node represents a different 
alternative solution. In tne missionaries and cannibals 
problem a node may represent the decision: wno gels in the 
boat to go to the opposite river banK? Each arc represents 
a different alternative: one or two missionaries, one or two 
cannibals or one missionary and one cannibal. By forcing 
this tree structure onto the problem, bacKtracKin^ 
algorithms do net have to be concerned with maintenance of 
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solved node lists or otner storage outside tne patn fror tr.e 
current node to tne root of tne tree. In fact, tne state 
space tree is implicit in bacttraci aigoritnms and not 
explicitly stored. 

Representation of tne solution by a vector of 
decision solutions corresponds directly to tne patn in tne 
state space tree explicitly stored at any time by a 
bacKtracic algoritnm. In our state space model tnis patn is 
tne current state. Tnis direct solution representation 
precludes a requirement to construct a solution once tne 
searcn nas concluded. 

Tne problem defined constraints on solution element 
relationsnips allow bacitracK aigoritnms to test tne current 
sequence of decisions (patn from root to current node) and 
prune tne implicit searcn tree witnout explicitly examining 
all nodes of tne tree. Tne time efficiency of a bacxtracic 
alfforitnm, measured by tne number of nodes examined, is a 
function of now well constrained tnese relationsnips are. 
Tne ti^nter tne constraints, tne less nodes will be 
examined. Witnout constraints, tne algoritnm will examine 
all nodes of tne state space tree. 

K QUEENS Problem Hepresenta tion 

An example representation will illustrate now a 
simple combinatorial problem can be represented for solution 
by a baclctracic algorithm. Tne problem, traditionally used 
to explain hacxtracK, is tne K QUEENS problem. Simply 
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Slated, me K QUEENS problem Is to find all possible board 
positions on a KxK cnessboard for K queens sucn mat no 
queen aitaclts any otner queen. From me rules of cness, we 
must find all positions sucn mat no two queens are on me 
same row, on me same column, or on me same diagonal. 

To represent tnis as a series of decisions we note 
mat no two queens may be on me same row. Also, if we are 
to place E queens on a KxK. board, mere must be at least one 
queen on eacn row. It follows mat mere must oe one and 
only one aueen on eacn row of me board. Therefore, me 
decision to maice at level i of me tree is where to place 
me queen on row i. 

The solution vector returned will be a path from me 
root to a leaf of the tree. Position i of me vector will 
represent the positioning of me queen on row i. Thus me 
solution will nave me form 
X = (x(l ) , X (2) , ... , x(K) ) 

wnere eacn x(i) is me position (column number) of me queen 
on row i . 

The constraint relationships can also be determined 
from the rules of cness. These constraints reflect tne 
facts mat no two queens can be on tne same column or 
diagonal. To express the column constraint in a computable 
form we note mat our representation would depict two queens 
in tne same column as two elements of me solution vector 
having tne same value. iie can restrict tnis with tne 
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constraint: 



column constraint 

FOR ML x(i) ,x( J) IN X 
[i^J => i(i)?^i(j)] 

Tne diagonal constraint is a little more difficult. Two 

queens are on tne same diagonal if tneir row distance is tne 

same as their column distance. For example, aueens at row 

and column positions (l 4) and (3 6) are on tne same 

liaffonal as are queens at positions (l 4) and (3 2). We can 

tnus suotract tne queens' row numbers and column numbers and 

then compare tneir absolute values to determine if they are 

on tne same diagonal. This gives us the diagonal 

constraint : 

diagonal constraint 

FOR ALL x(n,x(J) IN X 

[It^J => abs(i“j )7^abs(x(i )“x( j ) ) 

One final constraint identifies a path as a solution and 

thus may be termed a solution constraint. This constraint 

is identified by the fact that K decisions must be made to 

place 5 queens on tne board. A computable solution 

constraint is tnus iengtn(X) = K. The complete 

representation is given in Figure 1. 

C. GENERAL DESCRIPTION OF THE STRATEGf 

Bacictraclc is best defined as an uninformed, exhaustive* 
depth first tree search strategy. The strategy is 
uninformed, in that it does not employ problem specific 
icnowledge about now to search for a solution state. It is 
exhaustive in that it will implicitly or explicitly examine 
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all possible solution states as It executes. It Is a tree 
searcn strateey because It Implicitly structures tne problem 
Into a tree wnicn represents solution states by a patn from 
tne root to a leaf. It Is a deptn first strategy because It 
fully examines a subtree defined oy one alternative before 
It begins examination of tne next alternative. 



DECISION STRUCTURE 

decision(i) = column placement for queen on row 1 
SOLUTION STRUCTURE 

<X> wnere eacn X = (x(l), x(2), ... ,x(K)) 

wnere x(i) = column number for queen on row 1 

CONSTRAINT STRUCTURE 
element constraints 

FOR ALL x(l) ,x( j ) IN X 
[l5«j => x(l )?^x( j )j 
[i^^j => a bs ( 1-J )5^a bs ( x(i )-x ( J U J 
[1 <= x(i) <= XJ 
solution constraint 
lengtnrX = X 



FIGURE 1 

X QUEENS Problem Representation 
A baclctracic strategy attempts to construct a solution 
vector one element at a time. After decidin? on one 
element, tne strategy will expand tnis solution one element 
furtner. If tne strategy determines no expansion is 
possible and a complete solution nas not been acnieved tnen 
it will bacfftracK, cnange its most recently made decision, 
and try to expand tne new partial solution. 

To implement tnis strategy, a bacKtraoii al^oritnm taKes 
as an input parameter a description of tne patn from tne 



24 



root of tne state space tree to tne node bein^ expanded. 
The algorithm will expand this node by creatine ae isc r ipt ions 
of ail possible paths from the root through the expanded 
node with length equal to one greater than the parameter 
patn. Tne algorithm will then examine these new paths in an 
arbitrary order. This examination first tests the path for 
a solution and returns tne patn if it is found to be a 
solution. If not a solution, it tests for any violation of 
a predefined subset of tne problem constraints. If a 
violation is found, the algorithm determines no solution can 
be found with further exploration and terminates search on 
this path and all possible extensions. If there are no 
constraint violations, tne path is recursively expanded to 
search for a solution deeper in tne tree. 

Recursion is the natural form of expression for 
bacttracK algorithms. Usin^ standard program 
transformations Horowitz and Sahni IRef. 17J and (xerhart and 
Yelowitz [Ref. ISj nave developed iterative bac st racKi n? 
procedures from their recursive algorithms. This paper, 
since it is not concerned with efficiency Issues, will 
develop algorithms and schemas in recursive notation and 
leave for later program transformation worK tne translation 
into Iterative notation. With this in mind. Figure 2 ^ives 
a simple bacKtracS: function in a procedural notation. 

The efficiency of a bactctraclc algorithm principally 
depends on now tne patn element constraints contaireo in tne 
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predicate FEASIBLE 


are defined. 


The pruning efficiency 


of 


the predicate is 


direct ly 


related 


to the flegree 


of 


constraint being 


tested. Tne 


more 


constraining 


the 


relationships, the 


more pruning 


will 


be accomplished. 


As 



liscussed abovet tne pruning constraints will often be a 
subset of tne total problem constraints. For these reasons, 
a good heuristic is required for selecting the appropriate 
constraints if a good bacKtraciing algorithm is to be 
developed by a programmer or an automated synthesis system. 
A synthesis design method based on such a heuristic is thus 
desirable. 

The computation of tne predicate FFASIBLS nifrnlights one 
further characteristic of the strategy. The relationships 
expressed in the predicate often involve data about tne path 
elements. This data must be visible to the predicate, wnich 
normally implies extensive parameter passing at each call of 
tne function. The data relevant to each element of tne path 
is very often static, however. The data can be seen as 
properties of tne separate elements, and the constraining 
relationships as relationships between tne elements' 
properties. For this reason, many ba citt racKi ng algorithms 
establish these properties as global data, wnich can be 
accessed from any level of tne recursion. 



PROBLEM (PARM_LIST) <- BACKTRACK (NIL) 
wnere 

FUNCTION BACKTRACK (PATH) is defined as 

ALTERNATIVE_SET <- GENERATE ( PATE , PARM_LIST ) 

generate is a function whicn will return all 
extensions to PATH 

SOLQTION_SET <- {>; 

FOR P IN ALTERNATIVB_SET DO 
IF SOLUTION (P) 

THEN SOLUTION_SET <- S0LUT10N_SST U (?) 
solution is a predicate wnicn returns 
true if tfte parameter is a solution 
to tne problem 

ELSE 

IF FEASIBLE (P) 

THEN SOLUTION_SET <- 

SOLUTION_SET U BACKTRACK (P); 
feasible is a predicate wnicn returns 
true if the parameter can be expanded / 



END for; 

RETURN S0LUTI0N_SET; 
END BACKTRACK 



FIGURE 2 

General Bacirtracs Function 

The algorithm described above is a simple description of 
a bacictraci strategy which returns all solutions in tne 
problem defined state space. Two other variants of 
bacUtract often arise. The first variant is a strategy 
Which returns only the first solution discovered. The 
second variant returns only tne best solution encountered, 
wnere tne solutions nave been ordered by seme scoring 
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function. Botn of tnese variants require aaditionai control 
features wnicn complicate tne basic bacictracir strater:/ and 
will not be further discussed in this paper. For tnose 
interested, Gernart and Yeiowitz [Ref. 19J provide furtner 

discussion of this topic. 
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IV. A BACKTRACK RSDUCTION RULE 



A reducii 
aas two co;Tipo 
for subscnema 
for a simpi 
subalfforitnms 
reduclnfi* tfte 
specification 
the required 
problems are 
the reduction 



on rule for implementing a bacfct 
nents, the program schema and tne 
specification. This chapter uev 
e bacstracir algorithm with si 
. A design method is then 
problem specification into 
s. Tne method is based on an 
relationships of the three subal 
then examined to illustrate tne 
rule . 
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A. SCHEMA DEVELOPMENT 

In developing a program 
describe completely the expected 

desired output from tne schema and tne series of 
transformations on tne input t- 
perform to produce the output, 
then be translated into lower le 
tne language combining forms, 
derive a schema in tne desired functional language using 
this procedure. 

1 • The Expected Input 

From the general discussion of tne oacKtracic 
strategy (see page 23) we can describe tne expected input 
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and its salient cftaracteristics . Wnen a bactctracK function 
is invoiced it is passed one parameter, a vector 
representation of a partial solution to tne problem. We 
will call this vector PATH, since it is a path from tne root 
of the state space tree to the last node (last element of 
the vector) examined. PATH is of untnown leneth, since the 



function 


is 


called at every 


level 


of the 


s ta te 


space tree. 


A null PATH 


can also exist. 


Which 


Indicates no 


decisions 


have yet 


been made. This is 


tne 


pro blem 


state 


wnen tne 



initial invocation occurs. 

Although tne length of PATH is unicnown, tnere are 
characteristics wnicn can oe inferred. The most significant 
is that PATH nas been determined not to be a solution. If 
the previous invocation of tne function nad determined that 
PATH was a solution then tne function would nave terminated 
prior to the recursive invocation we are concerned witn. A 
second characteristic is that PATH meets tne test of the 
predicate feasible. A major assumption of this design 
method is tne conclusion that although PATH may not satisfy 
all tne output conditions required by the problem 
specification, it satisfies a major sunset of tne 
conditions. Furtnermore, there is reason to expect that an 
expansion of PATH will eventually satisfy all tne output 
conditions. The current bacitracH: Invocation must therefore 
search for all such expansions. 
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Anottisr input issue concerns the problem lata wnicn 
will be required by tne lower level functions.- The 

assumption made in tne development of this paper is teat 
this data will be made global. Figure 2 (see page 27 ) 
demonstrates how this is accomplished. All program 
specifications developed will declare this data as a 
parameter to the program, then declare the BACKTRACK 
function and lower level functions at the same scope level, 
providing tne required visibility. The alternative is to 
declare the data as input to BACKTRACK and pass it as a 

parameter to every recursive call of the function. In the K 

QUEENS example tne only data is the value of K. The cost of 
passing tnis parameter will be minimal. In other examnles, 
such as the Processor Sequencing Problem we discuss later, 
the data is much more extensive and tne parameter passing 
costs are higher. In any case, it is simpler to consider 
this data as global and not oe concerned with the mechanics 
of creating parameter lists. 

2 • The Ee si. red Output 

The output from a bacKtracA algorithm is also a 

path or list of paths. These paths, in vector form, 

represent all possible solutions to tne problem. Each 
invocation of tne oacirtracfc function examines a suotree of 
tne state space tree to search for an extension to PATH 
wnicn terminates in a solution. The snorter PATH is tne 
deeper the subtree examined will be. In any subtree there 
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is a possibility of zero, one or more solutions wnicn >iil 
be returned to the invocation examinins’ that subtree-. The 
baclttraclr function must compose these separate path 
solutions into a list of subtree solutions. 

3 • Ih£]il Transformations 

The input transformations are also apparent from 
the strategy description (see pa^e 23). There are three 
transformations to perform. The first of tnese is an 
expansion of the current partial solution by one additional 
decision. At the simplest level this transformation must 
produce a set of all paths which are possible expansions of 
PATH. Each path in this set represents expansion of the 
partial solution by one additional decision element. Each 
possible decision is represented by a corresponding element 
in the set. The result of this transformation is a set of 
paths to be examined. 

The second transformation is to execute a series of 
conditional tests. These tests perform tne examination of 
each path produced by tne first transformation. The 
significant characteristic of tne strategy is tnat the tests 
and resultins action are completed for eacn patn before any 
processing besrins on any other patn. We will call tne patn 
under consideration TSST_PATH. The tests and actions can be 
subdivided into two sets. The first set tests for a 
solution. If a solution is discovered, tne action is to 
return TEST PATH. If tne first test fails, the second set 
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tests for feasibility of expansion. If tnis test deciles 
expansion is feasible, tne oacjctracic function is recur-slvely 
called wltn TEST_PATH as the parameter. If the test fails 
no further expansion is feasible and the nil path is 
returned to signify no solution is found. 

Tne final transformation is required to eliminate 
the nil paths in tne solution once all expansions nave been 
examined. After this transformation is complete, the value 
returned will consist of a list of solutions. 

4 . S enema Translation 

Translation into a program schema requires grouping 
desired transformations into lower level functions ana 
specifying the appropriate functional forms for relating the 
inputs to and outputs from tne functions. Tne ability to 
separate the bacKtracK strategy into three transformations 
of tne input implies that we can define three lower level 
functions to perform the transforms. The following 
paragraphs develop these three functions and the proper 
combining forms. 

The first transformation operates on tne input to 
the schema, the parameter PATH. Tnis allows specification as 
a direct function application to tne parameter. The output 
of this application is to be a list of all patns wnlcn are 
expansions of PATH. Since the operation is to venerate all 
possible expansions, we will name tnis function GENERATE. In 
our lan^ua^e notation tnis is: GENERATE: PATH . 
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Tne second transformation operates on tne output of 
the function GENERATE. Its metnod is to operate on an 
element, return a value, operate on tne next element, return 
a value and continue until tne list provided by GENERATE is 
einausted. Tnis operation is clearly an example of tne 
APPLT-TO-ALL functional form available in our language. 
Since tne operation is a test of eacn element of tne list we 
will name tne function TEST. In our lan^ua^e notation tnis 
is : 

TEST (GENERATE: PATH) 

Ve fcnow more about tne benavior of tne function TEST, 

nowever. TEST is a conditional function witn two 

predicates. We can furtner specify TEST witnin tne scnema 

by employing this knowledge. Tne first predicate is a 

solution test. Tne resulting action is to return tne patn 

if the predicate nolds. In our laneua^e tnis is: 

SOLUTION :TEST_PATH -> I D :TEST^PATH; 

Tne second test is a cneclc for feasibility. Tne action is 

to recursively call tne bacKtracx function witn tne patn as 

parameter. Tnis can be expressed in our language as: 

FEASIBLErTEST^PATH -> BACKTRACK : TEST_PATH ; 

Tne final action of tne function is to return nil. Tne use 

of an anonymous function definition will allow definition of 

TEST witnin tne scnema as follows: 

M lambda<TEST_PATH> 

{ (SOLUTION:TEST_PATH -> II):T£ST PATH; 

FBASIBLE:TEST_PATH -> BACKTRACK : TEST_PATK ; 

NIL)}) 

(GENERATE :PATH) 
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Tne final transformation eliminates all null lists 



in the list returned by tne partial schema aoove.- Tne 

appropriate lower level function and combining form already 
exist in our laneuaffe. Tne functional form INSERT will move 
the function APPEND through tne list and eliminate all null 
list occurences. All that is required is to compose this 
function and combining form onto tne partial schema to 
produce tne bacttracic scnema of Figure 3. 

I I 

1 BACKTRACK :PATH ! 

I /APPEND ! 

! (a(lambda<TEST_PATH> ! 

! { (SOLUTION:TEST_PATH -> ID:TEST_?ATH,‘ ! 

1 FEASIBLB:TEST_PATH -> BACKTRACK : TES T_PATK ; ! 

I NIL)}) • 

I (GENERAT£:PATH) ) j 

I I 

FIGURE 3 

BacKtracK Program Scnema 

B. DESIGN METHOD FOR SUBSCHEMA SPECIFICATION 

The schema developed above is only one component of tne 

required reduction rule. Also necessary is a desisrn method 
for specifying tne lower level functions GENERATE, SOLUTION 
and FEASIBLE. A rule for derivation of these 
subspecif ications must be based on tne expected input and 
output of tne functions and the relationships between the 
functions wnicn tne scnema exploits to solve tne problem. 
Tne reduction rule developed in tne following paragraphs 
builds from tnese relationships. Tne rule provides a 
specification schema for each for eacn lower level function 
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and a method for instantiating tne scnemas for a g’lven 
proDlem instance. THe metnod is a pattern matcninp process 
wtiich replaces references to tne problem specification in 
tne scnemas wi tn tne referenced components of tne problem 
specification. In developing tne schemas the notation useo 
below is tne same as tne problem specification notation, 
with two additions: Capital letters refer to tne components 
of tne specification and lower case letters refer to the 
function or problem specification. Thus Op refers to tne 
output condition of tne problem specification, wnile Os, Of 
and Oe refer to tne output conditions of tne functions 
SOLUTION, FEASIBLE and OENEHATS respectively. 

1 . GfEN SRATE Spe£i f.1 cailon Ssnso^ 

To derive a general heuristic for specifying the 
generate function we need to closely examine the output 
requirements for tne function. Bacictracic requires C-SnEHATS 
to produce all single decision extensions to PATH. It is 
significant tnat GENERATE is tne only function in tne schema 
which produces output. Eacn element of tnis output is a 
potential solution. Tne implication is tnat GENERATE must 
perform all computation required to const uct a decision 
element and append it to PATH. Tnis computation may require 
incorporation of constraints from tne problem output 
condition. The K OUSENS problem provides a simple example. 
In tnis problem there is a direct constraint on tne value of 
tne decision alternatives, tnis beln? that tne column number 
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for eacH Iscislon !nust be between one ana K. Failure to 



Include t&is constraint in GENERATE may result in tde 
production of an infinite sequence of patn extensions. 

A neuristic to support this reasoning can be 
designed. If a constraint exists wnicn places direct 
restrictions on tne computed value of a decision element 
tnen tnis constraint snould be included in tne specification 
for generate. Wnat constitutes a ’’direct restriction" is not 
well formulated, but two general principles are offered. If 
a constraint restricts a decision element by a specified 
relation to constant values, tnen tnis is a direct 
restriction. The K OGEENS constraint above fails in tnis 
category. Secondly, if a constraint is formulated as an 
equality between a decision element and a computable value, 
tnen the constraint directly restricts the decision. Ve 
will Show an example of this later. On a more general note, 
the issue of which function to include constraints in is a 
major point of concern to algorithm designers and is further 
addressed in tne section on schema limitations. 

There are otner output conditions for tne GENERATE 
function. If GENERATE is to produce single decision 
extensions to PATH tnen tne length of eacn element of tne 
output must be one greater tnan tne length of PATE. Also, 
eacn element of the output minus its last decision is equal 
to PATH. A clean symmetry exists between these constraints. 
\Ve have restricted the size of each element of the output. 
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tbe value of tae last decision of eacn element, and tne 



values of tne rest of tne decisions. Tnis su^^ests a 
completeness in tne specification. Tne complete output 
condition Og can be expressed as: 

Os = FOR ALL TEST_PATH IN PATH_LIST 

[lengtn (TEST_PATH) = l+lengtn:PATH S, 
tlr(TEST_PATH) = PATE & 

Op£(last(TEST_PATH) ) J 

wnere Opg = subset of Op wnicn directly 
restricts a decision 

Tnere are certain conditions Known to be true of tne 
input. As discussed in tne paragrapn on scnema development 
PATH is Known to be feasible. Tnis fact may be used by tne 
syntnesis system and needs to be represented as an input 
condition. Tne specification input condition is tnus : 

FEASIELE(PATH) 

To derive tne domain and ran^e of GENERATE we need 
to examine tne reiationsnlps between tne input and output of 
tne function and tnose of tne problem. Generate accepts as 
input a patn representation for wnicn it is to generate 
allowable expansions. Altnougn not a solution, PATH is tne 
proper type of a solution. Ve can discover tne solution- 
type by examining tne range of tne problem. Tne problem is 
to produce a seouence of solutions. Tne range of tne 
problem is tnus a sec^uence of tne desired type. Given a 
problem ran^e of <Y>, wnicn signifies a sequence of objects 
of type I, wnere I is a lansuaare type we can extract Y as 
tne domain of GENERATE. Tne function must output a sequence 



38 



of objects, eacti of wriica is a potential solution. Tnis is 

tne same output type as tne problem and tne pro ciem- range 

can be substituted for tne range of GENERATE. Tnis produces 

a domain and range specification of: 

Dg = Y wnere Rp = <Y> 

Rg = Rp 

Tne complete specification scnema is given in Figure A. 

2. SOLUTION S;peci f ica tl on Scnema 

Tne function SOLUTION Is tne simplest of tne lower 

level functions to specify since It relates directly to tne 

entire problem specification. SOLUTION is a function wnicn 

accepts a patn representation as input and returns a boolean 

value. Tne representation SOLUTION tests is tne same type 

as tne elements of tne problem domain. In tne K CUEENS 

problem, for example, tne problem ran^e is <LI3T(N)>. Ve 

want tne program to produce a sequence of lists, wnere eacn 

list is a solution. Tne corresponding domain for SOLUTION 

is simply LIST(N). Since tne function is a predicate, it 

must return a boolean value. Tne domain and ran^?e can tnus 

be specified as: 

Ds = T wnere Rp = <Y> 

Rs = 3 

To derive tne input and output specifications we note tnat 
SOLUTION must return true when tne problem output conditions 
applied to tne parameter TSST^PATH are true and must return 
false wnen tne problem output conditions applied to tne 
parameter are false. Tnis can be expressed as a logical 
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equivalence between me boolean value returned and tne 
problem constraints appi i ed to tne parameter T1JST;_?ATR . 
Since some of the constraints may be included in GENERATE, 
we need only include the subset not in GENERATE. Tne input 
condition follows from tne input condition to GENERATE. 
Since the input to GENERATE is Known to be feasible, the 
input to SOLUTION minus the last element must be feasible. 
Tne input and output conditions may be expressed as: 

Is = FEASIBLS( tlrtPATH) 

Os = Ops(TEST_PATH) <=> b 

where Ops = subset of Op not included 
in GENERATE specification 

The complete specification scnema is given in Figure 4. 

3 • IlASXBLS S^ec i f i caii^n Schema 

The specification of FEASIBLE is more difficult than 
that for SOLUTION because the feasibility test is the less 
constraining of the two. An assumption of this design 
method is tnat FEASIBLE is a relaxation of the constraints 
represented by SOLUTION. One rule for relaxing restrictions 
is to eliminate one or more expressions within a conjunctive 
statement of constraints. We attempt to develop a heuristic 
for identifying which conjunct or conjuncts of the 
constraints stated in tne problem output conditions to 
include in tne feasibility test. 

Tne bacKtracK scnema expects certain characteristics 
of the path being investigated. A path which is feasible 
yet not a solution fails to meet one or more of the output 
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conditions. However, it is feasible tftat an expansion of 
tne patn nay neet all tne output conditions. k- pain 
determined to be unfeasible also fails to meet one or more 
of tne output conditions. Tne difference is tnat an 
unfeasible patn will never meet all tne output conciticns, 
no matter wnat sequence of decisions is appended. If we can 
specify tne type of condition wnicn, wnen failed by a 
partial solution will also be failed by any extension to 
ttiat partial solution, tnen tnis tnowled,?® can be added to 
our reduction rule. 

A. heuristic can be formulated to express this 
/knowledge. A constraint wnicn addresses tne solution as a 
whole is not of tnis type. If tne patn as a single entity 
fails a condition, tnen any expansion to tne patn produces a 
different entity, and may pass tne condition. A constraint 
which limits tne relations between tne parts of tne solution 
is of tnis type, nowever. If a partial solution exhibits a 
conflict between two elements tne same conflict win exist 
no matter what subsequent elements are appended to tne 
path. The conclusion is tnat tne appropriate constraints 
are a subset of tne problem output conditions and can oe 
selected by an heuristic process which retains only those 
constraints wnicn relate elements of the proposed solution. 
Tne input and output conditions can be expressed as: 
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If = FEASIBLB( tir:PATH) 

Of = Opf (T£ST_PATH) <=> D 



wnere Opf = ail conjuncis of Op wnicft 

relate elements of TEST_PATH 
and are not in GENERATE 

Since FEASIBLE is a component of tne same 
conditional expression as SOLCTTION, tne domain remains tne 
same. Since it is also a predicate, tne rane-e remains tne 
same . 

Cf = T wnere Rn = <Y> 

Rf = B 

Tne complete specification scnema is driven in Figure 
C. THE fC QUEENS PROBLEM 

Our first example to illustrate tne use of tnis 
reduction rule will be tne K QUEENS problem aiscussed 
earlier. The format to be followed in presenting tnis and 
later problems will be to represent tne problem witn tne 
structure in Figure 1, develop a formal specification of tne 
problem, and tnen apply tne reduction rule of tne two 
previous paragrapns. Tne output will be a program 
satisfying tne problem in tne form of tne bacictracic pro^-ram 
scnema witn formal specifications for tne lower level 
functions. 
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generate specification schema 

GENERATErPATH = PATH_LIST sucn tnai 
FEASIBLErPATK => 

FOR all test path ELEMENT OF PATH_LIST 

[lengtnlTEST_PATH ) = 1+1 engtn ( PATH ) S 
tlr(TEST_PATH) = PATH 
Opf (iast(T£ST_PATH) )J 

wnere GENERATE;! -> Rp suca tnat Rp = <T> 

and Op? = subset ot‘ Op sucn tnat ail ronjuncts 

of Op wnicn directly restrict decision 
elements are in Opg 

Heuristic; To identify Op elements for Opg select 
tnose in wnicn eitner 

1) a single decision element is restricted 
by constant values OR 

2) a single decision element is restricted 
by an equality 

SOLUTION SPECIFICATION SCHEMA 

SOLUTION;TSST_PATH = D sucn that 
b <=> [FEASI3LE( tlr;PATH) => Ops (TEST_PATH ) J 

wnere SOLUTION:! -> B sucn tnat Rp = <y> 

and Ops = suDset of Op sucn tnat all conjuncts 
not in Opg are in Ops 

FEASIBLE SPECIFICATION SCHEMA 

FEASIBLE;TEST_PATH = b sucn tnat 
b <=> l?SASIBLS( tlr;PATH) => Opf (TEST_PATE )] 

wnere SOLUTION;! -> B such tnat Rp = <!> 

and Opf = subset of Op sucn tnat all conjuncts 
which relate decision elements and 
not in Opg are in Opf 



FIGURE 4 

Reduction Rule Specification Schemas 
^ "§£I®sent a t Ion 

Tne required problem representation was developed in 
Figure 1 (see pase 24). 



2 • Eio Specification 

The components of the formal prooiem specification 
may be extracted directly from the problem representation. 
Tne domain of tne problem is the type of tne variable input 
parameter. For tne K QUEENS problem tne variable parameter 
is K, the natural number denoting tne size of the 

cnessboard. The domain is tnus N, tne natural numbers. Tne 
ranse of the problem is tne type of tne solution structure. 
For the K QUEENS problem tne solution is expresses as a 
sequence of lists of natural numbers. Each list represents 
one solution and tne sequence lists all solutions. Tne 

domain and range specification can tnus be specified as: 
K_QUEENS:N -> <LIST(N)> 

Tne output condition is derived from the problem 

constraint structure. It is simply tne conjunction of all 

constraints in tne problem representation, formulated in an 

appropriate logical specification. Using X to represent a 

solution and ?ATH_LIST to represent tne sequence of =11 

solutions the output condition is: 

FOR ALL x(i),x(j) IN X, X IN PATH_LIST 
[i5^j => x( i ) ^x( j ) 6. 

i5^j => abs ( i-j )?^a bs( X ( i )-x( j ) ) & 

1 =< x(i) =< KJ 

S. length:! = K 

The input condition is derived from tne observation tnat tne 
program should produce valid output regardless of the value 
of the input, as long as the input is of the proper type. 
This type restriction is already provided by tne domain 



lesi^natioa. Tne input condition is tnus vacuously true and 
reduces the truth of tne Input/output implication tt> tne 
truth of the output condition. Tne complete specification 
is given at Figure 5. 



5_0aEENS:F: = PATH_LIST sucn that 
true => FOR ALL x(i).x(j) IN X, 

X IN PATH_LIST 
[i=?«j => x(i^^x(j) 6 

i9<j => aos( i-j )#absf x(i )-x( j ) ) ^ 

1 <= x(i) <= 5 J 
^ iengtn(X) = K 
Where X QUEENS :N -> <LIST(N)> 



FIGURE 5 

X QUEENS Problem Specification 
3 • Functi on Specification 

'^e will now apply our reduction rule to tne formal 
X QUEENS problem specification. The application of the rule 
will instantiate the specification scnemas for the lower 
level functions and produce a oacirtracx schema with formal 
specifications for the lower level functions. Our 

discussion of tne rule application will illustrate tne 
pattern matching process. Any reference to tne problem 
specification within tne function specification scnemas will 
cause a search of tne problem specification for tne desired 
components. These components will tnen be inserted into tne 
instantiated function specification. For example, tne 
GENERATE schema specifies tne ranee of GENERATE to be tne 
range of the problem specification. In instantiatine tne 
GENERATE specification the range in the problem 



specification is extracted and inserted into tr.e function 
specification. In inis manner, ail lower level function 
specifications are produced. 

For the K QUEENS problem the specification is 
listed in Figure 5 and the reduction rule schemas are listed 
in Figure 4. We begin tbe rule application by developing the 
specification of GENERATE. Tne schema lists the domain as: 

Dff = Y where Rp = <Y> 

Since tne problem specification lists Rp as <LIST(N)>, Y 
matches LIST(N) and we nave Dg = LIST(N). Similarly, the 
match for Rg produces <LIST(N)> as the range for GENERATE. 
The schema input condition is listed as true, wnicn requires 
no match since there is no reference to tne problem 
specification. The output condioa references the problem 
specification only in the conjunct: 

Opg( last( x( i ) ) ) 

where Ops’ = subset of Op which directly 
restricts decision 

Bmployinff our heuristic for identifying constraints wnicn 

directly restrict decisions, the constraint: 

FOR ALL xfi) IN X 

11 =< x(i) =< KJ 

meets tne first case and is inserted into tne GENERATE 
specification. All components of the specification nave now 
been produced and are included in Figure 5. 

Schema instantiation for the SOLUTION function is 
accomplished with tne same procedure. The specification 
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scaema lists tne domain of SOLUTION as; 



Ds = Y wnere Rp = Y 

The problem specification lists Rp as <LIST(NO, wnicn 

allows a ma ten between Y and LIST(N). List(N^ is tnus 

identified as the domain. Tne senema specification lists 2 

as the range, which requires no match with tne problem 

specification. Tne input condition also remains true, since 

no problem reference is required. Tne output condition does 

reference the problem specification in: 

Os = Ops (TEST_PATH) <=> b 
wnere Ops = subset of Op not inciudea 
in Ope 

'!ie tnus extract all conjuncts of tne problem output 

condition not listed in tne output condition for GENERATE 

and place them in the output condition for SOLUTION. These 

conjuncts are: 

FOR ALL x(i) ,x( j ) IN X 

[ii^J => x(i)?tx(j) & 
i?^j => abs ( i-J )7^abs ( x( i )-x( J ) ) J 
^ length:! = K 

The complete specification for SOLUTION is listed in Figure 

5 . 

The procedure for FEASIBLE is tne same. Tne domain 
and ranee schema specifications are tne same as for SOLUTION 
and produce a domain of LIST(N) and a ranee of E. The input 
condition remains true. Tne output condition specification 
of : 
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Of = Opf ( TSST_PATH) <=> D 

wnere Opf = subset of Op wnlcn includes ail 

conjuncts wnlcn relate elements 
of decision and are not in Opg 

references Op and forces identification of tnose constraints 

not in generate wnlcn address tne decision elements. From 

tne problem specification tnese are easily identified as: 

FOR ALL x(i) ,x( J) IN X 

=> x(l)?fx(j) ^ 
abs (i-J )?fabs(x(i )-x( j) )J 

Tne complete specification for FEASIBLE is given in Figure 



^ Genera ti on 

To furtner illustrate tne program syntnesis process 
we will develop programs to satisfy tne specifications for 
tne lower level functions. Tne development process will not 
be detailed but will be only generally described. 

Development of tne function GENERATE will be 
discussed first. Satisfaction of tnis specification can be 
accomplisned by a program wnlcn constructs a sequence of 
lists. Eacn list is constructed by appending one natural 
number to tne input patn. Tne natural numbers must fall 
between one and 5. A simple program wni cn accompllsnes tnis 
is : 

GENERATE: PATH = 

AUX_GENERATE:<PATH. 1> 
wnere 

AUX_GENERATS:<?ATE, C0QNTSR> = 

(SCUAL:<C0UNTER, K> -> APPENDR :<PATH , COUNTER>; 

APPSNDL: tA?PSNDa:<PATH, C0UNTER>, 

AGX GENERATE : [PATH, ADD:<1, COUNTER>J ) 



K^CUEENSlK = 

BACKTRACK: nil 



wne re 

BACKTRACKtPATH = 

/APPEND 

( ck ( la 7 )bda<TEST_PATR> 

{( SOLUTION :TEST_PATH -> ID : TEST_PATH ; 

?EASIBLE:TEST_PATH ~> BACKTRACK : TEST.PATR ; 
NIL)}) 

(GENERATE: PATH) ) 

GENERATE.-PATH = PATH_LIST sucn tnat 
FEASIBLE:PATH => FOR ALL TEST_?ATH IN PA?H_LIST 
[iengtn(T£ST_PATE) = 1+leaein ( PATH ) \ 

tlr(TEST_PATH) = PATH 5. 

1 <= last (TEST_PATH) <= K J 

waere GENERATE: LIST (N ) -> <LIST(n)> 

SOLUTION :TEST_PATH = D sucn tnat 
b <=> {FEASI£LE(tlr:TEST_PATH) => 

FOR ALL x(i),x(1) IN TEST_PATH 
( i/J => X ( i )itx ( J ) & 

=> abs (1-j ) ;^abs (x ( i )~x ( j ) ) J 
S lsngtn(TEST_PATH) = K} 

wnere SOLUTION:LIST( N ) ~> B 

FEASIBLE :TEST_PATH = b sucn tnat 
b <=> {FSASI£LE( tlr:TEST PATH) => 

FOR ALL x(i),x(iT IN TEST_PATH 
[l5^j => X ( i )9«x ( J ) S. 

=> a bs ( i~J ) 7 «a DS (x( i )~x( j ) ) J 
wnere FSAS IBLE:LIST(N ) -> 3 



FIGURE 6 

K QUEENS Program Specification 
The next function to be developed is FEASIBLE. We 
wish to develop SOLUTION after FEASIBLE since SOLUTION 
properly includes all tne constraints in FEASIBLE. This will 
allow inclusion of FEASIBLE within SOLUTION. FEASIBLE is 
expressed as a conjunction of two constraints. This 
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transidtes into me AND of two computaoie Dcoiean 
expressions. Tne first expression compares tne values of 
all elements in tne parameter. Tne input condition tells us 
tnat all elements in tlriPATH meet tnis condition. 
Therefore we only need compare tne last element witn tne 
rest of tne elements. The second expression compares tne 
absolute values of tne difference of tne row positions and 
tne difference of tne column positions. Since we Know tnat 
tnis condition nolds for all elements of PATH except for tne 
last, we only need test tne last element. Tnis gives us tne 
program: 

FSAS IDLE: PATH = 

AND: [ROW_MATCR:PATH, 

DIAG_MATCH:PATHJ 

wne re 

R0V_MATCH :PATH = 

(NULL: path -> true; 

AND : [NSOUALS: [LAST:PATH, 1 :PATHJ . 

ROW MATCH(TL :PATH) J ) 

DIAG_MATCH:PATH = 

(NULL:PATH -> true; 

AND: [NEOUALS[ABS(-: [TL:PATH, 1:PATHJ ) , 

ABS(-: LLENGTH:PATH. iJ)J, 
DIAG_MATCH(TL:PATH)J ) 

Tne derivation of tne function SOLUTION is now 
simple. S OLUTI ON contains tne conjunction of tnree 
constraints. Two of tnese are included in PSASIBLE. We can 
include FEASIBLE and tne final constraint in an AND function 
to complete tnis program. Tnis gives us: 

SOLUTION: PATH = 

AND: [FEASIBLE -.PATH, 

EQUALS :[E, LENGTH :PATHJ J 

After derivation of tnese programs tne syntnesis system 
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would repiacs ttie specifications of Figure 6 witn 
programs and tne process would oe complete. 



ne s e 



D. THE PROCESSOR SEOOSNCING PROBLEM 

Tne Processor Sequencing Proolem is a tnown NP complete 
problem (Ref. 20). It differs from tne E QUEENS problem in 
tnat tne patn elements under examination at any stage of tne 
process nave a number of associated properties and tne 
constraint rela ti onsdi ps are expressed predominantly in 
terms of tnese properties. Tne solution to tnis problem 
will illustrate tne use of global data in ba cict racKin£r 
algcritnms and tne incorporation of constraints into tne 
function GENERATE. 

I • Eic bl em Hgpr» s g.nia t ion 

Tne Processor Sequencins Proolem (PSP) may be simply 

stated: Given a set of tasis to be run on a single 

processor, witn eacn tasit naving an associated release time, 
processing time and deadline, does tnere exist a scneduiing 
sequence wni cn will complete all tasKs prior to tneir 

deadline? Tne associated properties place a series cf 

constraints on tne tascs. Tne release time is an earliest 
possible availability constraint. No tasst is available to 
run before its release time. Once selected for execution, 
each tasx will consume exactly the amount of time specified 
by its processing time. Tne deadline places a latest 
completion constraint on eacn tasit. 
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Tne first tasi in representing tnls proriem is to 
lecile on a lecision structure. One obvious component- of a 
decision is wbicn tasu to run next. But tnis is not 
complete in tnat more information is required about 

scheduling this tast than mere selection provides. Tne time 
the tasK is scheduled to run is also a crucial part of the 
lecision. This time is not fixed based on tne previous 
decisions in the partial solution vector, tut depends on 
additional information. For this reason, the decisions made 
for this problem can be represented by a pair, the first 
element being the taslc selected and tne second element beina* 
tne start time of the taslc. 

Tne second representation tas£ is to transform tne 

decision structure into a solution structure. Tne solution 

structure will consist of a sequence of decisions, eacn 

lecision being of tne form specified ty the decision 

structure. Thus a solution will nave the form: 

X = ( x(l ) , x(2) , ... , x(n ) ) 

where each x(i) is of form 
( tasic(l), timed) ) 

The final representation tasic concerns tne problem 
constraints. A number of constraints relate the elements of 
the possible solutions. The first we will consider is tne 
leadline restriction imposed on each tasK. Whether a tasic 
meets its leadline depends on two factors: the tasic start 

time and tne tast processing time. The start time is an 
element of tne decision being tested. The processing time 



52 



and deadline tl-Tie are constant values associated witn eacn 



instance of tne problem. A tasfc meets its deadline -if tne 
sum of the start time and the processing time is less tnan 
the deadline. This can be expressed in computable form as: 
FOR ALL i(i) IN X 

[deadline( tass( 1 ) ) >= start(i) + time ( tasic( i ) ) J 

where deadline, time are problem constants 

Another solution element constraint is identified by tne 

fact that no tasic may be scheduled twice. Thus each tasit in 

the sequence must be distinct, can represent this by 

noting that if the position of two tasics in the sequence are 

distinct, then tne tasics must also be distinct. This can be 

expressed as: 

FOR ALL x(i),x(j) IN X 

[ i#j ==> tasK(l )^tasic( j ) J 

There are also constraints on tne start time or each tasK. 
These limit the start time to a point after both the 
completion time of tne previous tasu and the release time of 
tne tasK under consideration. It follows that tne start 



time may 


be expressed as tne 


maximum 


of tne 


two 


constraints 


. Assuming a language 


function 


to select 


tne 


maximum of 


two natural numbers. 


this constraint may 


be 



expressed as: 

FOR ALL x(n IN X 

L start(l)=max( release (tasx(i ) ) , 

start ( i“l )+process ( tasK( i-1) ) 

where release, process are problem constants 

The final constraint identifies a solution from potential 
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soiulions wnlcn meet all oitier constraints. 



If ail otner 



constraints are met and tne numoer of elements of tne 
proposed solution equals tne numoer of tasis, tnen we itnow 
tnat all tasts are included in tne sequence. Tnis final 
constraint can oe identified as our solution constraint and 
is expressed as: 

LSNGTErX = £ 

Tne complete prooiem representation is given in Figure 7. 



DECISION STRUCTURE 

deccision(i) == itn tasir to run 

start time of tasir 

SOLUTION STRUCTURE 

<X> wnere eacn X = (x(l)» x(2), ... ,x(£)) 
where x(i) = (tasir(i)» start(i)) 

CONSTRAINT STRUCTURE 
element constraints 

FOR ALL x(i) ,x( j) IN X 

[ ii^j => tasic( i )?ttasic( j ) J 
FOR ALL x(i) IN X 

[ d eadline ( tasit( i ) ) >= 

start(i) + process( tasK( i ) ) j 
FOR AIL x(i) IN X 

[ start(i) = max( release ( tasK( i ) K 

start ( i-1 )+process( tas”t(i-l )) ) J 

solution constraint 
lengtn(X) = K 

wnere release, process, deadline are prooiem constants 



FIGURE 7 

PSP Problem Representation 
2 Specification 

As witn tne K QUEENS problem, tne four components of 
tne PSP formal problem specification can be easily derived 
from tne problem representation. The domain for tne PSP 
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In mis case, 



problem is me type of tne variable input, 
trie variaole input is tr.e number of tasss, K, a n'aturai 
number. Tiie solution structure should provide us tne 
ran^»e. In this case, a single solution is structured as a 

list of pairs of natural numbers. The first element of tne 
pair is a tast identifier and the second element is a start 
time for that tasK. Since the problem requires a sequence 
of all solutions, the proper ranse is a sequence of lists, 
tfe can express this as: 

PS?:N -> <LIST(NiN)> 

The problem output condition is imm:ediately derived 
from tne constraint structure. It is merely the conjunction 
of all constraints we nave identified. Tne expression of 
this output condition is more complex tnan for the I OUEKNS 
problem because tne constraints rely on constant values 
defined by tne problem instance. Our notation for declaring 
these constant values will be tne wnere declaration of cur 
profframmine language. Tnis declaration in effect defines a 
scope of visibility for tne constants, maicing tnem Known to 
the constraints. The problem output condition is: 

FOR ALL x(i) ,x( J) IN X 

U/J => tasK(i )^tass( j) dv 
deadline( tasK( 1 ) ) >= 

start( i ) + process ( tasK( i ) ) & 

sta rt ( i )=max( re lease (tasK(i)), 

start ( i-1 )+process ( tasK( i-1 ) ) )J 

length: X=K 

where release, process, deadline are program constants 
For reasons tne same as witn tne K QUEENS problem the input 
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condiiion is vacuously true. 



Tne complete specification is 



given in Figure 8. 



PSP:K = TASK_LIST sucn tnat 

true => FOR ALL x(i),x(j) IN X, X IN TASK_LIST. 

and x(i) = ( tasK:( i ) , s tart( i ) ) 

[l3^J => tastd )^tasli( J ) & 

deadline( tasK( i ) >= 

start ( i )+process ( tasi£( i ) ) ^ 

start(i) = max( release ( tasK( i )) , 

start ( i-i )+pro cess ( tasK( i-l )) ) J 

S iengtn(X) = K 

wnere PSP:N -> <LIST(NxN)> 

and release, process, deadline are problem inputs 



FIGURS S 

PSP Problem Secification 
3 « Specification 

We now apply our reduction rule to produce a 
bac)ctracic program witn formal specifications for tne lower 
level functions wnicn will solve tne PSP problem. To do so 

we use tne scnemas of Fiffure 4 and tne formal problem 

specification of Figure 8. Ve oe^in witft tne specification 
of tne function GENERATE. Tne specification scnema lists tne 
domain as T, wnere Rp = <I>. Matcnins tnis ae-ainst tne 

problem specification provides Rp as <LIST(nxN)> wnicn gives 
Y as LlST(NxN). Tnis is placed as tne domain of GENERATE. 
Tne scnema lists tne range as Rp so we nave: 
GENERATE:LIST(NxN) -> <LIST(NxN)> 

Tne scnema input condition does not reference tne problem 
specification so it is copied into tne GENERATE 

specification. In a liie manner tne first two conjuncts of 



56 



tne scnema output condition are copied into tne Gi'NiL’RATi; 
specification, Tne final conjunct references Ope-, tne 
sunset of tne problem output conditions wnicn directly 
restricts a decision element. Examining tne problem 
specification under tne guidance of our neuristic produces a 
matcn witn tne conjunct: 

FOR ALL x(i) IN X, X IN TASK_LIST 

and x(i) = (tasK(i), start(i)) 

[start(i) = max( release ( tasic(i ) , 

start ( i-1 )+process ( tasK( i-1 )) ) J 

and case two of tne rule. Case two prescribes tne inclusion 

of problem constraints wnicn in tne GENERATE function if a 

constraint restricts a single decision element cy an 

eiualiiy. In tnis case start(i) is tne decision element and 

it is restricted by an equality. Case one produces no matcn 

since no constraint bounds a decision element by constant 

values. Tne scnema entry for Opg is replaced by tne 

conjunct above producing tne full specification of Figure 9. 

Tne same procedure is used to develop tne formal 
specification for SOLUTION. Tne scnema specifies tne domain 
as Y wnere tne problem range is <T> . Tne problem range is 
<LIST(NxN)>, wnicn produces a Y matcn of LIST(NxN), wnicn we 
tate as tne domain of SOLUTION. Tne scnema range does not 
reference tne problem specification, so it is copied into 
tne function specification. Tne same is done for tne 
function input condition. Tne scnema output condition 
references Ops, tne subset of tne problem output condition 
wnicn is not included in Opg. From tne discussion in tne 
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last paragrapn tnis raduces to tns first, second and foiirtn 
conjuncts in tne proolem output condition. Rspiaci-n? Ops 
witn tnese conjuncts produces tne specification of Fiffure 9. 

Tne specification for SOLUTION is identical to 
FEASIBLE, as snown in tne scnemas, witn tne exception of tne 
output condition. In tnis case, tne reference to Cpf in tne 
scnena must be replaced by all conjuncts of tne prcbierri 
output condition wnicn relate decision elements and are not 
in Opff. Witn tnis problem tne last conjunct does not relate 
decision elements since it addresses tne solution as a 
wnoie. Tne tnird construct is included in 0pp. Tnis leaves 
tne first two constraints to be substituted for Opf . Placinp 
tnese constraints into tne scnema produces tne specification 
of Figure 9. 

E. schema LI.'-ITATIONS 

Tne reduction rule developed in tnis cnapter nas a 
number of limitations. Tne principal deficiency is tnat it 
is neurlstic in nature and not an algoritnm. Tne underlying 
reason for tnis is tne failure of tne rule to incorporate 
any proof mecnanism in its actions. It is believed tnat a 
proof mecnanism may be constructed based on tne design 
metnod developed above. Reduction rules for tne simple 
divide and conquer control strategy nave been developed by 
Smitn [Ref. 2iJ wnicn employ a proven tneorem as tne oasis 
for specification development. 
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! PSP:K = 

I BACKTRACSC :nii 

1 wnere 

! BACKTRACE .-PATH = 

I /APPEND 

1 iof^ (lamDda<T£ST PATH> 

1 1 (SOLUTION:TEST_PATH -> I D :TBST_PATH » 

! FEASIBLE:TEST_PaTH -> BACKTRACK:TEST_PATH; 

I NIL)}) 

I (GENERATE:PATH) ) 

1 GENERATErPATH = PATH_LIST suer, tnat 
! ESASIBLErPATH => FOR ALL x(i),x(j) IN X, 

! X IN PATH_LIST 

! and x(i) = ( tasi5:( 1 ) ,start f i ) ) 

! [iengta(X) = i+iecgta (PATH) & 

1 tir(X) = PATH 

I start(i) = frax ( relea se( tasic( 1 ) ) , 

! stand -l)+process(iasK(i-l)))J 

I w.dere GENERATE: LIST ( NxN ) -> <LIST(NxN)> 

! SOLUTION :TEST_?ATH = D suen tnat 
! D <=> {FSASIBL£( tir:T£ST_PATH) => 

I FOR ALL i(i),x(j) IN TEST PATH 

1 wnere x(i) = (tasitTi). start(i)) 

I => tasir( 1 )i4tasK( j ) & 

I deadllne( tasic( i ) ) >= 

! stan( i)+urocess( tasKd ) J 

1 ^ ienetn(TEST_PATH) = K) 

I where SOLUTION :LIST( NxN ) -> B 

I FEASIBLE:TSST_PATH = b suen tnat 
1 b <=> i?EASI3LE( tlr:TSST_PATH => 

! FOR ALL x(i),x(j) IN TEST_PATH 

1 wnere x(i) = (tas 2 (l), start (id' 

1 [i^j => tasir(i)/tasx(j) S 

! deadline( tasK:( i ) ) >= 

! s tart ( i )+process ( tasitd ) ) J } 

! wnere FEASIBLE: LIST( NxN ) -> B 

j wnere release, deadline, process are program constants 



FIGURE 9 

PSP Program Specification 
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A second iimitaiion of tne rule is tne inefficiency 



innerent in tne DacxtracK scnema. As eviaencei D-y our 
examples mere is mucn duplicate computation oetween tne 
SOLUTION ana FEASIiLi) predicates. Tnls could indicate tnat 
efficiency is better served oy evaluating tne FEASIBLE 
predicate first and tnen nestine a dimlnisned form of tne 
SOLUTION predicate witnin tne action clause of FEASIBLE. 
Altnougn our design metnod would allow tnis, it restri^'ts 
tne scnema to problems wnere tne FEASIBLE constraint 
includes only restrictions witnin SOLUTION as well. It is 
not unown wnetner tnis is a general condition wi tn problems 
suitable for tne bacxtracK solution tecnnlque and tne mere 
seneral scnema of Figure 3 was developed instead. 

A general efficiency concern in tne development of any 
bacitraclt al^oritbrn is tne proper subdivision of constraints 
between GEN EH ATS and tne otner functions. Obviously, any 
constraint witnin GENERATE filters nonfeasicle partial 
solutions from SOLUTION and FEASIBLE. How mucn total 
computation is saved is not clear, nowever. Tne total 
number of nodes examined by tne predicates is less wnen more 
of tne constraints are included witnin GENERATE, but tne 
computation required by GENERATE is greater. A general 
conclusion tnat seems valid is tnat some work: is saved if 
tnere is also duplicate computation, as discussed above, 
between SOLUTION and FEASIBLE, but if tnere is no duplicate 
computation, tnen eacn extension at eacn level visited is 






tested once against eacn constraint. A more t'avoraole area 
for related investigation is in program transformation. 
Tnis worif may Identify wnen bacKtracK programs produce 
duplicate computation, and transform sucn programs to 
eliminate tfie duplication. 
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7. AN EXTENSION TO EACKT5ACK 



Tile t)acKiracK alfforltnm nas iraaltionaiiy been employed 
10 solve problems oi‘ tne type described in Cnapter III. 
Researcn on tne stratesy nas been oriented towards 

efficiency improving tecnniques, [Ref. 22, 23j program 

proving [Ref. 24 J , problem representation formalisms [Ref. 
25J and control structure abstraction [Ref. 2t> , 27J. Tne 

problem of extending tne strategy for solution of a 
different class of problems nas not been significantly 
addressed. Tne second reduction rule proposed by tnis paper 
extends tne tacKtracK strategy by adapting it for solution 
of tne problem reduction problem type. Tne result is a 
general purpose scnema witn a neurlstic design metnod for 
lower level function specification. As tnis result is less 
rooted in existing knowledge, tne design metnod presented 
will be described in general terms. 

A. PROBLEM REEUCTION PROELSM REPRESENTATION 

A problem reduction problem representation is another 
formalism for symbolic problem description. As witn tne 
state space representation discussed in Cnapter III, 

representation of a problem witn a problem reduction format 
will impose a particular grapnic structure onto tne 

problem, 'rfitn tnis structure we can employ a grapn searcn 
procedure to searcn fcr a solution. Tne goal in tnis 
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caapter is to adapt tne bacKtracx strategy to searcr. tae 
problem reduction grapn. In tnis paragrapn we win- first 
develop tne representation, tnen depict tne grapn structure 
produced by tne representation, and tften illustrate a sample 
problem representation. 

1 E§PI®l®nt a t i on 

There are tnree sey components of a problem 
reduction representation. The first component is tne 
problem state. Tais is a symbolic description or tne state 
of the problem at any point in the searcn process. Tne 
initial problem state is a description of a ?oal wnica is to 
be satisfied. As tae searcn process executes, tne initial 
goal state will be decomposed into one or more sub^oal 
states, wnica, wnen botn are satisfied, will cause tne 
original goal to be satisfied. An example of tnis is tne 
symbolic integration process. Given a goal state of tne 
f orm : 

/(f(x) * g(x)) dx 

where f,? are jrncwn functions 

A solution to tnis problem is a symbolic representation of 

tne integral. An initial decomposition may produce tne two 

su bgoais : 

/f(x) dx 
/g(x) lx 

where f,g are icnown functions 

Solving botn of these two subgoals will lead to tne solution 
of the original problem. In tnis case, tne two subsolutions 
must be added. 



63 



In order to decompose states and compose solutions 

some means must be provided for tnese actions. Tne second 

component of a problem reduction representation is a set of 

reduction rules. £acn rule will act on a goal description 

and provide one or more decomposed subgoals. Tne rule also 

provides a metnod for combining solutions to suogoals into 

solutions to tne original goal. Tne most significant aspect 

of rule application is tnat all subgoals must be solved for 

tne original eoal to be solved. In our symbolic integration 

example tne reduction rule applied may be of tne fern: 

If Integrand is form f(x) + g(x) 

wnere x is variable of integration 
tnen 

solve f(x) ana g(x) 
compose solutions wltn + 

It is important to note tnat tnere is an applicability 
condition (If) and a conjunctive solution. 

Tne representation we nave described tnus far allows 

only goal decomposition. The tnira component of tne 

representation allows for a solution of a subset of eoais we 

will call primitive. Tnis component is a set of rules, also 

called primitive, wnicn, wnen applied to a primitive ?oal 

will return a solution. In our symbolic integration 

example, one primitive rule may be: 

If Inte^rrand is of form cos x 

wnere x is variable of integration 
then return sin x 

Tne primitive operators provide tne only means of fincing a 
solution in a problem reduction representation. Tney are a 



means to represent tnose goals wnicn we icnow now to lirertly 
solve. 

2* And/Or Tree Hepreienia t i on 

Tne grapn structure imposed by tnis representation 
is similar to tne structure of a state space tree, but 
contains an additional node type. We win represent seal 
descriptions by nodes and rule applications by arcs. Tne 
path from tne root of a tree to a subgoal description 
describes tne sequence of rule applications wnicn produced 
tne ffoal description. Siven a node (goal description' tnere 
is a ranee of reduction rules wnicn may be applied. Tnis 
range is represented by tne set of arcs leavlne tne node. 
Tne complicating factor of tne problem reduction 
representation lies in reduction rules wnicn decompose a 
goal description into two or more subgcais. Tne 

relationsnip between tnese subgoais is tigntiy constrained, 
representing tne fact tnat botn of tnese subgoais must be 
solved to solve tne goal. Tnis logical AjND relationsnip 
contrasts witn tne subgoals produced by tne otner reduction 
rules. Satisfaction of tne subgoais produced by any 

reduction rule will satisfy tne goal. Tne grapnic solution 
is to tie tosetner tne arcs representins application of one 
rule witn a nyperarc. Tnis creates an AND node, wnicn 
signifies tnat all descendants of tne AND node must be 
satisfied. Tne application of distinct rules are 

represented by OR nodes, or arcs not connected by nyperarcs. 
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wnlcii represeni me lo^^lcai OR nature of meir 

relationsnip. Figure lo depicts a sample searcn space. 
Oiven an initial goal represent ed as node A, tnree reduction 
rules can be applied. Rule i produces subgoals B and C, 
rule 2 produces sube-oal D and rule 3 produces subgoals S and 
F. A can be solved by solving eitner set of goals, B and C, 
or D, or S and F. Ultimately, if B and C are to be solved 
t&en G or H, and I must be solved. If D is to ce solved, 
tnen J and £ must be solved. If E and F are to be solved, 
tnen L and M and N must be solved. To solve tnis problem 
tae searcn process must searcn for subeoals wdicn can be 
solved by primitive operators and tie to^etner tne separate 
patas represented by and nodes. Unilice tne state space 

searcn, tne result of tnis searcn process vili be a solution 

tree. From any node tne separate brancnes represent tne 

different subgoals produced by a single rule application. 
As an example. Figure 11 depicts tne four solution trees 
present in Figure 12 if ail leaf nodes can be solved. 

2 • in Examu l.e Re presentation 

Tne example we present nere and develop for tne 
remainder of tne cnapter is a simple aritnmetic tneorem 
prover. Given a goal statement in terms of an aritnmetic 
assertion in any number of variables, and a number of 
propositions about tnose variables we snow to be true, can 
we prove tne statement is true. In tnis parae*rapn we will 

develop a problem reduction representation for tne problem. 



anl in later paragrapns we will alapt me DacictrarK control 
strategy to searcn tne representation defined AND/OR tree 
and return a proof of tne assertion. 



A 




FIGURE li) 
AND/OR Grapn 




FIGURE 11 
Solution Grapfts 

To represent our prooiem witn a prociem reduction 
fornalism we need to define tne tnree components of tne 
representation. Tne first component is tne ffoal 
description. Tne initial goal is an aritnmetic assertion. 
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A. suitable goal description is tne assertion itself. Tne 
result of applying a reduction rule will be one or- more 
suberoalSt eacn of wnicn snould be a simpler arltnmetic 
assertion. For our problem representation we can express 
tnis as: 

GOAL DESCRIPTION 

form: aritnmetic assertion 
initial : [B (A + C) J /E > B 

Tne initial e>oai description represents tne particular 
problem instance to solve. 

Tne next component we describe is tne set of 
primitive rules, Tnese rules need to be described before 
tne reduction rules because tney provide tne basis towards 
wnicn tne reduction rules snould simplify tne goal. 
Primitive rules represent tne Knowledge possessed about tne 
problem. They specifically apply to ^oai descriptions teat 
can be directly solved. In tne tneorem prover, tnese rules 
are expressions of tne propositions wnicn are Known to be 
true. For tne problem instance we are concerned witn tnese 
are : 

PRIMITIVE RULES 
A > 0 
B > 0 
C > 0 
S > fcJ 
C > E 

To complete our problem representation we need only 
specify tne reduction rules. Tne purpose of a reduction 
rule is to simplify a g’oal state wnicn cannot be directly 
solved by a primitive rule. It follows tnat reduction rules 
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smDody general tnowiedge about proDlerr area relaticnsnips 
wnicn allow transformation of goal descriptions into one or 
more simpler descriptions. In simple theorem proving tnese 
relationships can be described with logical implications 

Which represent general Known theorems. They can be stated 
in the form: 

PI 5. ?2 ev ... 6 PK => Pe 

Where P0 represents a goal and PI, ... ,PK represent 
subgoals. If P0 can be matched against a goal description, 
then subgoal PI ... PK will oe produced. We will use four 
reduction operators for the theorem prover: 

REDUCTION OPERATORS 
i>0 S. y>2? => x-y > 0 

x>0 6 . y >2 => i+y > z 

i>0 & y>z => x’^y > x’^z 

x>z=^y ^ y>0 => x/y > z 

Tne complete problem representation is given in Figure 12. 



&OAL DESCRIPTION 

form: arithmetic exnression 
initial: [3 (a + C)J / E > B 

PRI^ITI'/S RULES 

A > 0 3 > 0 

C > 0 E > 0 

C > £ 

REDUCTION RULES 
x>0 S, y>0 => 
x>0 S y>z => x+y > z 
x>0 S. y>z => x^Y > 

X > z^y & y>0 => x/y > z 



FIGURE 12 

Theorem Prover Problem Representati on 
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B. SCHEMA DEVELOPMENT 



In developing tne oactctrscK sctenia for a prociem 
reduction representation tne procedure descrioed in Cnapter 
IV will again be followed. Tnls procedure requires 

description of tne expected input* description of tne 
desired output* identification of tne operations required to 
transform tne input to tne output and tnen translation of 
tne operations into lower level functions and appropriate 
functional forms. 

1 • lug. c ted Input 

As in tne state space bacAtracit scnema a 

representation of a patn is expected as input. Tnis patn is 
a symbolic description of tne sequence of rule applications 
wnicn nave reduced tne initial goal description to tne 

current ffoal description. Since tne patn does not include 

tne current ?oal description* tnis must also oe included in 
tne expected input. Tne resulting input is a sequence 
consisting of a patn and a symbolic representation of tne 
current goal. 

Tne relevant cnaracteristics of tne input are two. 
Tne first is tnat all rules in tne patn nave been 

successfully applied. Tne second is tnat tnis current goal 
may be pri.mitive. Tnis situation is a result of tne 

bacJttractt strategy applying tne SOLUTION predif'ate before 
tne FEASIBLE predicate. Tnis will be furtner discussed in 
tne section on input transformations. 
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2 • ire 4 Output 

Tfte output desired 



from a problem recuction 



representation is often dependent on tne proDlerr. For 
example, tde desired output for tne symbolic integration 

problem is a symbolic description of tne integral. Witn tne 
simple tneorem prover we desire proof of tne input 

assertion. A commonality between tnese ana ail problem 
reduction representations is tne sequence of operations 
performed to arrive at a solution. For tnis reason tne 
general output desired will be a solution grapn consisting 
of tne reduction rules and primitive rules applied to solve 
tne problem. The return from tnis most general case can be 
transformed into tne desired output form. 

3 . Input Transformations 

In describing tne input transformations required we 
will stay as close as possible to tne simple ba^'ictracK 
scnema developed in Cnapter IV. Tne goal is to produce a 
scnena wnlcn can be applied to eitner tne state space 
representation or tne problem reduction representa tion . Tne 
lesion metnod will differ based on tne problem 

representation. To do so we will identify tnose aspects of 
tne simple bacKtract scnema wnicn require ennancement to 
searcn an AND/OR grapn, and develop tnose ennancements in 
eitner tne scnema or tne design metnod. 

Tne initial transformation required is to extend tne 
patn parameter. In tnis case, tne extension consists of 
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appenain? one more reduciion rule to me patn of rules 
previously applied. Tnis extension does not apply tne'ruie, 
but lists it as one possible alternative. Tne result of 
tnis transformation will be a new sequence of patn, state 
pairs. Eacn pair represents a different alternative 
extension to tne patn of applied rules. 

Tne second transformation is tne conditional test. 
Tne SOLUTION predicate will again be executed first. In a 
problem reduction representation a solution is not 
recognized by examining tne sequence of decisions (rule 
applications), but by examining tne current ^oal 
description. Upon recognition of a solution, tne action is 
to return tne sequence of rules, and not tne ^oal 
description. If tne SOLUTION predicate fails tnen tne 
FEASIBLE predicate will be executed. Tnis predicate is a 
test of tne patn to determine if a solution can feasibly be 
discovered tnrougn expansion of tne patn. Tne clearest way 
to test tnis in a problem reduction representation is to 
test tne reduction rule appended by tne patn expansion 
transformation. If tnis rule can be applied to tne goal, 
tnen furtner sub^oals can be produced wnicn nay lead to 
solutions. If tne rule can be applied tnen tne appropriate 
actions are more complex tnan tnose in tne state space 
scnema. Tne obvious first action is to apply tne rule and 
produce new subgoals. If only one subgoal is produced we 
nave created an OP. node. In tnis case tne appropriate 
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aciion is lo recursively call tne DacKiraclc function wi in 
tfte new sub^oai and patn. If :nore tnan one suD,e9ai is 

produced an AND node nas been created and more complex 

action is required. If an AND node is created tnen a 
separate patn is created for eacn descendant of tne node. 
To solve tne AND node eacn patn must return a solution. To 
solve this problem by a bacKtracK searcn we must searcn eacn 
patn and compose tne solutions. If any patn returns nil, 

tne result of tne node will be nil. Tne order of 

transformations on AND node is tnus to apply tne rule, 
create separate <PATH, D0 aL> pairs for eacn subgoal, 
bacKtracK on eacn pair and finally compose solutions. 

The final transformation is to filter tne nil 
solutions returned by tne examinations of tne expansions. 
Tne value returned will consist of a list of solutions. 

^ Transla ti on 

To derive a scnema from tne required transformations 
we will again group the transformations into lower level 
functions combined with the appropriate functional forms. 
The first transformation is tne generation of sxpahied 
paths. This transformation can again be accomplished by a 

single function GENERATE. In o^r language notation tnis is* 
GENEHATE:<PATH, GOAL> 

v'nere tne parameter PATE is a representation of the s^qu^nce 

of rules applied, and tne parameter GOAL is a description of 
tne current goal. 
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Tne second transf orna ti on is tne conditional testing 
function. As witn tne state space representat io n , tnis 
function is applied to one element of tne output of 
and tne results are returned before it is applied to tne 
next element. This APPLT-TO-ALL operation is: 

OCTEST (GENERATE:<PATH, G0AI> ) 

we can expand tne function TEST since Know tne actions 
required of it. The first predicate tests tne goal for 
being primitive. If it is, the action is to return tne 
path. Tnis can be expressed as: 

SOLUTION:GOAI -> Ii}:PATH; 

The second predicate is a test for feasibility of 
expansion. Tne correspondinsr action is to apply tne rule, 
decompose the path, subgoals pair into separate path, 
subgoal pairs, apply bac?ctracK to eacn pair and finally 

compose tne results. This can be expressed as: 
FEASI£LS:<PATH, GOAL> -> 

COi'^,POSE( eacktrack(decc^:pose:<?ath, goal>)); 

Using tne lambda definition of our lansruage ve now nave: 

(lambda <PATH> 

{(S0LUTI0N:G0AL -> II):PATH; 

EEASIBiE: <PATH, GOAL> -> 

C0MP0SE( £ACKTRACK;(rECOMPOSE:<PATH, GOAl> } ) ; 
NIL))) 

(GENERATS:<PATH, GOAL> ) 

The final transformation filters the nil values 
returned by the process. Tnis can be expressed as inserting 
the APPEND function throueh the list of solutions returned. 
Tne complete schema is ^iven in Yii'ure lib. 
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1 BACKTRACfC:<PATH, (}OAL> = 

1 /APPEND 

i ( (lamDda<PATH> 

! i (SOLaTION:GOAL -> IDiPaTH; 

I FEASIBLE:<PATfl,GOAL> -> 

! COMPOSE( BACtCTRACK(DECO?^POSS:<PATH,GOAL> ) K 

I NIL)}) 

I (G£NERATE:<PATH,GOaL>) ) 



FIGURE 13 

BacKtracK ProffraTi Scnsrra 
C. SUBSCHEMA SPECIFICATION 

Tne scnena developed above proviaes a structure for 
composinff tne solutions to tne subprociems GENERATE, 
SOLUTION. FEASIBLE, DECOMPOSE and COMPOSE. A design netnod 
for specifying tnese su bpro bierris is also required. Tnis 
parasrapn discusses tne relations nips between tne functions 
tne scnema requires to solve a problem. A detailed design 
metnod similar to tne metnod presented in Cnapter 17 is net 
developed, but left for furtner researen. 

1 . gen SPATE S ueci f i ca t i on 

Tne function GENERATE must accept an input pair 
wnicn represents tne patn of reduction rules applied and tne 
current goal specification. Tne output must oe a sequence 
of pairs. Eacn pair contains a new patn representation and 
tne goal specification. Tne new patn is tne input patn to 

wnicn one reduction rule of tnose available to apply nas 
been appended. Tne sequence contains a separate pair for 
aacn available rule. As an example, if GENERATE is given 
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tile input: 

<(R1, R3, R2), GOAL> 

and tnere are four reduction rules R1...R4 availacie to 
apply tnen GENERATE must output: 



«(R1, 


R3, 


R2, 


Rl), 


G0AL>, 


<(R1, 


R3, 


R2, 


R2), 


GOAL>, 


<(R1, 


R3, 


R2, 


R3 ) , 


G04L>, 


<(R1, 


R3, 


R2, 


R4), 


G0AL» 



Tnls output represents all possible expansions of tne rule 
application patn. It does not represent ail expansions witn 
applicable rules. A different function of tne scnema will 
delete nonappl ica Die rules. 

SOLUTION Sueci f ica ti on 

Tne function SOLUTION will aeain De tne easiest to 
describe. Tne intent of SOLUTION is to test a i^oai 
description to see if it is a solution. In tne prooiem 
reduction representation tnere is one operation to test for 
a solution. If tne goal description can be solved by a 
primitive rule tnen a solution nas been found. Tne 
specification of SOLUTION must express tnis reiationsnip 
between tne eoal and tne primitive rules. Tne form of tne 
reiationsnip may differ from problem to problem. Eor 
example, in tne symbolic integration problem tne 
reiationsnip is an application. If a primitive rule can be 
applied to tne ?oal , tnen it can be solved. In tne tneorem 
proving problem tne reiationsnip is membersnip. If tne goal 
is a member of tne primitive rules tnen tne goal is solved. 
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^ • FSAS I BL£ Specification 

The function of tne predicate FEASiJiLfi is to test a 
path for the possibility it may lead to a solution. Tne 

path under consideration exhibits two cnararte ri s t ics . The 

last element of the path is a reduction rule which has not 
been applied to tne goal description. Tne remainder of tne 
path is a sequence of reduction rules which nave been 
applied to tne initial goal description to produce the 
current description. If tne oath under consideration is to 
be considered feasible, then tne last rule of tne path must 
be applicable to tne goal description. In more concrete 
terms, a reduction rule applies to a goal if tae rule 
produces one or more subgoals from tne goal. Tne FEASIBLE 
predicate must test this relationship between tne goal and 
tne reduction rule. It is significant that the FEASIBLE 
function does not actually apply the rule to produce 
subfi'oais. It need only ensure tne rule can oe applied. 

4 . MQ.2!^£0S E Specification 

If tne patn is feasible (tne rule can be applied), 
tne next step is to produce a <PATH, G0 aL> pair. This pair 
will be tne input to tne recursive call to BACKTRACK. In 
many instances tne application of a reduction rule will 
produce more than one subgoal. For tnis reason tne function 
DECOMPOSE must do more than apply the rule to orepare input 
for BACKTRACK. For every subgoal produced by tne rule 
application, DECOMPOSE must construct a <?ATH , GCAL> pair. 
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Tne patn in all pairs is identical; tne sequence of rule 
applications wfticn produced tne associated - ^'oai 
description. Tne ffoal description in eacn pair is uniuue: 
it describes one of tne subsoals produced by tne rule 
application. Tnere are ti*’o important cnaracterist ics of tne 
output of tnis function. If tne rule application produces 
only one subgoal, tnen tnere is only one <PATH, GOAL> pair 
produced, and tne APPLY-TO-ALL functional form of tne scnema 
reduces to a straignt application of BACKTRACK to tne pair. 
Tnis operation Is similar to tne state space bacKtraca: 
scnema. Secondly, DECOMPOSE nas transformed a <PATH, GOAL> 
pair wnere tne patn description contains a nonapplied rule 
(tne final rule) to a pair witn all rules applied and a new 
firoal description. This is tne type of input expected by tne 
function BACKTRACK. 

^ • COM PCS S Specification 

BACKTRACK is applied to eacn <PATK, GCAL> pair 
produced by DECOMPOSE. Tne result returned by tne 
application is a sequence of patns. Eacn patn represents a 
sequence of rules applied to tne goal description wnicn 
terminated in a solution. For ?oal descriptions wnicn could 
not be reduced to a primitive aroal tne algorithm returns tne 
nil patn. If tne nil patn is found in tne sequence of patns 
returned it signifies tnat one of tne suogoals produced by 
tne reduction rule is not solvable. From our discussion of 
tne problem reduction formalism, tnis means tnat tne goal is 



78 



not solvable witn tnls reauctlon since all subgoais proiucea 
must be solved to solve tne ffoal. Tne Inference is tnat tne 
sequence of reduction rules wnlcn produced tne subgoais does 
not lead to a solution and tne nil patn must oe returned to 
Indicate sucn. If no nil patn Is returned la tne sequence 
tnen all suogoals were solved and tne sequence Is returned. 

Figure 14 depicts tne requirements of tne lower 
level functions of tne problem reduction bacittracK- scnema. 

D. A SI'^.PLE ARITHMETIC THEOREM PROVSR 

Our example to illustrate tnls reduction rule is tne 
simple tneorem prover developed tnrougnout tnls cnapter. A 
formal problem specification will not be developed as tne 
informal description of tne reduction is not detailed enougn 
to exploit tne formalism of a specification. Instead, tnls 
paragrapn will develop informal specifications based on tne 
problem representation of Figure IH and tne function 
reauirements of Figure 14. 

1 . CEn ERA TS Specification 

Our problem representation lists a set of four 
reduction rules, R1...R4. GENERATE must produce a sequence 
of four <PATH, G0 aL> pairs. Eacn PATH will terminate witn a 
different reduction rule. Ve can express tnis in cur 
informal notation as: 

GENERATE:<PATH, G0aL> = «?ATH(l), GOAL> , <PATH (2 ) , G0Ai>, 

<PATH(3), G0AL>,<PATH(4 ) , GOAL>'> 

sucn tnat 

TLR:PATH(i) = PATH & 

TL:PATH(i) = ROLE(i) 
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This will provide the desired input to the conlitionei 



test . 



GENERATE REQUIREMENTS 

GENERATE: <PATH, GOAL> = NEV_STATE sucn tnai 
NEW_STATE = i<NEW_PATH, GOAL>! 

NEW_PATH = APPENDR:<PATH, RULE> for each RULE) 

SOLUTION REQUIREMENTS 

SOLUTION : GOAL = Doolean such that 

boolean <=> R1 : <PRIMITI VES . GOaL> 
wnere Ri is a problem dependent relation 

EEASI13LE REQUIREMENTS 

FEASIBLE : <PATE , G0AL> boolean sucn that 
boolean <=> R*£: [tlr :PATH, GOALJ 
Where R2 is a problem dependent relation 

DECOMPOSE REQUIREMENTS 
DECOMPOSE :<PATH, GOAL> = 

<<PATH, NEV_GOAL(l )>,... ,<PATH, NEW_GOaI(N)» 
such tnat 

[N = number conjuncts in precondition TL tPATHj b. 
R2:<C0NJUNCT( 1 ) , NEW_GOAL(i)> = 

R2: Itlr: PATH , GOALJ J 

COMPOSE REQUIREMENTS 

C0MP0S£:S0LUT10N_SEQUENCE = SOLUTIONS sucn tnat 
['^EMBER:<NIL, SOLUTION SECUENCE> => 

SOLUTIONS = NILJ 5. 

[NOT(MEMBSR<NIL, SOLUTION_SEQUENCE> ) => 

SOLUTIONS = SOLUTIONS SEQUENCE] 



FIGURE 14 

Reduction Rule Requirements 



2 • SOL UTI ON Specification 

Tne major difficulty in specifying the SOLUTION 
function is in determining tne appropriate relation between 
tne primitive rules and tne goal descriptior. In tne 
theorem prover problem we attempt to reduce tne initial goal 
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lescriptions to descriptions wnicn are Known to be true. 
Tfie descriptions Known to oe true are tne p-rociem 
propositions, wnicn tne problem representation designates as 
primitive rules. Tne problem, tnerefore, is to find ^oal 
lescriptions wnicn are in tne set of primitive rules. Tne 
appropriate relation is a memnersnip test and we can express 
tnis as: 

SOLUTION : GOAL = boolean sucn tnat 

boolean <=> :G0AL, PRIl^lTI VES>J 

3 • FEASISLE Spec i f i c a tioj 5 

Tne FEASIBLE predicate is a test of tne 

applicability of tne final rule of tne patn to tne current 
goal description. Tne specification question is to 

determine vnat relation tests tnis applicability. In tnis 
problem a goal description is given in terms of constants, 
literals and aritnmetic operators. Tne rules are expressed 
in terms of variables, constants and operators. An 
appropriate appl 1 ca bi l 1 ty test is a pattern matcn between 
tne conclusion of tne rule and tne goal description. Tnis 
test can match any subexpression or literal of tne goal 
against tne rule variables, out the constants and operators 
must be exact matcnes. If a matcn is found tne rule can be 
applied to tne soal. Tnis can be expressed as: 

FSAS IBLE: <PATH , G0AL> = boolean sucn tnat 
boolean <=> MATCH: [TL:PATH,GOALj 
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^ S S 2 ecif i.ca i.i on 

After tne predicate FEASIBLE nas determined tnat tne 
rule applies to tne ^oal description, DECOMPOSE must apply 
tne rule and construct a sequence or <PATH, GOAL> pairs for 
input to BACETHACK. To determine suoffoals we note tnat tne 
precondition of tne reduction rule lists tne form of tne 
subgoals to be produced. Tne difficulty in creating 
subsroals is in replacing tne rule variables witn tne problem 
literals and subexpressions. We can identify tne 
appropriate literals witn a matcning process identical to 
tnat conducted by tne feasibility test. For eacn subgoal 
produced DECOMPOSE must tnen create a <PATH, GOAL> pair. We 
can express tnese requirements as: 
decompose :<rPATH, G0AL> = 

«PATK, NEW_G0AI(1 )>,... ,<PATH, NEW_GOAl(N)» su-n tnat 
N = number conjuncts in precondition of TLiPATH ^ 

FOR BACH CONJUNCT(i) IN tlrrPATH 
MATCH:<CON JUNCTd ) , NEW_G0AL(iO = 

MATCH: [tlr: PATH, GOAL 

^ i£§£illi£.a t i 0 n 

Tne final function to specify is COMPOSE. Tnis is 
also tne simplest to specify. COMPOSE must return nil if 
nil is a member of tne parameter sequence. If nil is not a 
member of tne sequence tnen tne sequence is to be returned. 
Tnis can be expressed as: 

COMPOSE:SOLOTION_SEOUENCE = RETURN_S EOUEN CE sucn tnat 
[member :<N IL , SOLUTION_SECUENCE> => 

RETaRN_SSCUENCE = NILJ 6. 

[not (mB^BER:<NIL , SOLUT ICN_S EC USN C E> ) => 

RETURN SEQUENCE = SOLUTION SEOUENCEJ 



82 



Trie complete Informal specification for tne functions is 
ffivenatFIGURElb. 



I I 

! PROOF:<GOAL, PRIMITIVES, RUL£S> = I 

1 BACKTRACK :<NIL, GOaL> 

I where 

! BACKTRACK :<PATH, G0AL> = 

I /APPEND 

! (c< { la-n 0Ga<pATH> 

! { (SOLUTIONtGOAL -> ID:PATH; 

1 FEASIBLE:<PATH,GOAL> -> 

! COMPOSE( BACKTRACK (DEC0MP0SE:<?ATH, GOaL>) }; 

! NIL))) 

! (GENERATE :<PATH, G0AL> ) ) 

i GENERATE :<PATH, G0AL> = 

I «PATH(1), G0AL> <PATH(4), G0AL» 

I sucn tnat FOR ALL PATH(i) 

1 [TLR:PATH(i ) = PATH S. 

I TL:PATH{i) = RUL£(i)J 

! SOLUTIONtGOAL = Doolean such tnat 
! boolean <=> MEMBER :<GOAL ♦ PRIMITIVES> 

I FEAS IBLE :<PATH , GOAL> = boolean such that 
! boolean <=> MATCH : [TL tPATH , GOALJ 

i DECOmPOSE:<PaTH, G0AL> = 

1 «PATH, NEW_G0AL(1)> <?ATH, NEW_GOAL( N ) >> 

! sucn tnat 

I [N = number conjuncts in precondition tItPATH & 

i FOR EACH CONJUNCT! i) IN tirtPATH 

I MATCH:<CONJUNCT( i ) , NEW_GOAL(i)> = 

! MATCH: [tirtPATH, GOALJ 

1 COMPOSE: SOLUTION_SEOUENCE = RETURN such that 

1 [M£M3SRt<NIL, SOLUTION_SEOUENCE> => 

1 RETURN = NIL ^ 

I NOT{'"EMBERt<NlL, SOLUT ION_SEOUENCE>) => 

I RETURN = SOLUTION SSOUENCEJ 



FIGURE 15 

Theorem Prover Pro^?ram Specification 
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71. CONCLUSION 



Ttie success of future efforts in profirran synt-^.esis will 
depend In large part on tne ability of system developers to 
codify expert tnoviecge about tne programming process. As 
syntnesis systems become more complex and attempt to solve 
more difficult problems tne searcn space created in the 
solution process suffers tne effects of combinatorial 
explosion. As tne searcn space grows tne search strategy 
must become more efficient. Tne larger tne space tne closer 
tne searcn process must approximate a straight line searcn. 
The ability to execute a straight line searcn is a function 
of the Knowledge tne searcn strategy employs to solve tne 
problem. The better the Knowledge* tne fewer incorrect 
alternatives will be explored. 

Tne principal goal of this paper is tne development o-^’ a 
reduction rule for a syntnesis system based on tne problem 
reduction representation formalism. Tnis rule encapsulates 
specific Knowledge about now to solve a class of 
combinatorial problems. It includes a control strategy 
based on tne bacitracK class of algorithms and a design 
method for developing subprobiem specifications which, when 
solved, can be incorporated into tne control strates*y to 
solve tne original problem. It is believed that the design 
method is sufficiently specific to suine tne syntnesis 
process tnrougn tne first level specification of any problem 
in its class. 
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Tne seconlary ^oai of tnis paper is tne refinerrer.i of 
eeneral proeramming tnowledge concerning me Dac-KiracK: 
control structure. It is believed tnat current Enowiedge 
concerning tne strategy is deficient in two areas, wniie 
tne bacttracH: procedure has been schematized, ffeneral 
principles concerning the relationships between the 
components of tne procedure nave not been ''learly 
articulated. Tne design alternatives for tne lower level 
functions nave not been specified and tne relationsnip of 
the functions to tne problem nas not been defined. It is 
believed that the reduction rule of Cnapter IV can provide a 
design basis for programmers as well as a synthesis system. 

The second area of Knowledge refinement concerns tne 
extension of the basic strategy to a problem domain to which 
it nas not teen previously applied. Chapter V adapts me 
basic strategy to search tne AND/OR grapns produced by a 
problem reduction representati on formalism. Tne informal 
reduction rule developed in tnis cnapter can again be 
applied by programmers as a basis for design. 

The bacKtracK strategy is clearly not tne most efficient 
technique for searching state space or AND/OR trees. 
Whenever problem area inowled^e can be codified for use oy a 
control strategy, a search process wnicn selects a best path 
for expansion will be more efficient than a oacstracic 
search. In many cases it is either not possible to coalfy 
such ^nowledffe in an efficiently computable format or tne 
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ssarcn efficiency is not worm me acdel effort of incincinf^ 
ttie Knowledge. Tne bacKtracR strategy offers an attractive 

option. WitP readily availaole program scnemas and design 
metnods tne control strategy is easily developed. Once 
developed, tne strategy can significantly prune a searcn 
tree provided problem constraints are sufficiently 
restrictive, Tnis places empnasis on rigorous 
identification and specification of tne problem constraints, 
an activity beneficial to programming, 

Tnere are significant researcn areas remaining to be 
investigated. These include a formal proof of tne reduction 
rule proposed in Cnapter IV, formalizing the rule proposed 
in Cnapter V with a formal proof, inves ti e-at ion of 
efficiency improvine constraint allocation tecnniques for 
tne lower level functions FEASIBLE, SOLUTION and G-ENERATS, 
and other design metnods for tne bacKtracic stratep’y based on 
different assumptions tnan those discussed. 
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APPENDIX A 



THE PROGRAMMING LANGUAGE 



Tne following is a aescriptlon ot‘ tne pro^rranining 
lan^uaffe used in tne definition or tPe pro/?ram scnerr’as and 
developed examples. Tne descriptive format and most 
definitions are derived from Bacitus [Ref. xxj . 



A. THE SET OF OBJECTS AND TYPES 



B 



l§i2£i2lL on 

boolean values 



N 

I 

LIST(N ) 



natural numbers 
integers 

lists of natural 
num be rs 



<> 



sequence of objects 



values 

t rue 
false 

0 , 1 , ^ , ... 

.... ** It ^^t If iJf... 

nil 

( 1 ) 

(1,2.3) 

<nil> 

<1, 3. true, (2,3)> 



B. THE SET OF FUNCTIONS 

LH. 221 ion dom^n range 
s:x anv any 

tl:x any any 

id:x any any 



l»£ini ti on 

i f x=<Txl , . . . , xn> 
and n >= 5 
tnen xs 

else undefined 

if x=<xl> 
tnen <nil> 
i f x=<xl , . . . , xn> 
and n>=2 

tnen <x2 , . . . , xn> 
else undefined 

X 
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fu net ion 


lomain 


rangg. 


d£lini tion 


atom :i 


any 


B 


if X B or X N 
tnen true 
else false 


aqua 1 :x 


NxN 


E 


if x=<y, z> 
and y =2 
tnen true 
else false 


nsquai : x 


NxN 


B 


if x=<y,z> 
and y=z 
tnen false 
else true 


nu 1 1 : X 


LIST(N) 


B 


if x=nil 
tnen true 
else false 


ienfftn : x 


LIST(N) 


N 


if x=nii 
tnen 0 

i f x=<xl , . . . , xn> 
tnen n 


+ : X 


NxN 


N 


if x=<y,z> 
tnen y*z 


X 


NxN 


N 


if x=<y,z> 
tnen y-z 


and : x 


SxB 


B 


if x=<true, true> 
tnen true 
else false 


or :x 


Bx3 


E 


if x=<false, false> 
tnen false 
else true 


append r : x 


any 


any 


if x=<nil, z> 
tnen <z> 

if x=< (xl , . . . ,xn) , z> 
tnen <xl,...,xn,z> 
else undefined 


appendl :x 


any 


any 


if x-<z, nii> 
tnen <z> 

i f x=<z , ( xl , . . . , xn ) > 
tnen <z ,xl , . . . ,xn> 



else undefinea 



LU.SS.Il2n domain 
appendix any 



leiiniiioii 



111122 

any If x=<z, nii> 

or x=<nli»z> 
men <z> 

if x=<z , (xl , . . . »xn )> 
men <z , xl , . . . , xn> 
else undefined 

tlrix any any if x=<xl> 

men <nil> 
i f x=<xl , . . . , xn> 
and n>=2 
men <xl ♦ . . . , xm^ 
wnere .m=n-i 
else undefined 

abs : X I N ' x j 

note: me result of functions applied to invalid types is 

undefined 



C. THE APPLICATION OPERATION 

Tne application operation allows tne use of na-ned 
parameters. Function definitions include formal parameter 
names. Tne scope of tnese names is restricted to tne 
function application. Tne actual parameter/formal parameter 
correspondence is positional. If a single actual parameter 
is required tne syntax is as follows: 

f uncti on_name iparameter 

If multiple parameters are required, tney are listed as a 
sequence as follows: 

function_name:<parameter_l , ... , parameter_n> 

D. THE SET OF COMBINING FORMS 

form name def ini tion 

f('?:x) composition f:<^:x> 
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form 



name 



definition 



[fl, ... ,fnj:x construction 
(p:x f:y;?:z) condition 



<f 1 : X , ... , f r. : x> 

i f p : -X 

tnen f:y 
else g : z 

wnere x,y,z are named 
parameters not necessarily 
distinct 



/f : X 



insert if x=<xl> 

tnen xl 

if x=<xl , ... , xn> 

tnen f:<xl, /f :<xl , . . . , xn>> 

else undefined 



f :x 



apply to all if x=nil 

tnen nil 

if x=<xl , . . .xn> 
tnen <f : xl , . . . ,f :xn> 



S. THE FUNCTION DEFINITION MECHANISM 

Tne operator binds a function name to a function 
definition. Tne syntax is as follows: 

function name : <parame ter list> 

function definition 

Tne langua,^e also permits tne use of anonymous function 
definitions. Tne lamoda operator is used to define tne 
function as follows: 

(lamoda <parameter list> 

{function definition)) 

(actual parameter list) 
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